R-Card

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Version

This page defines a Higgins R-Card ("relationship card") as implemented in Higgins 1.1.

Introduction

This section provides an introduction to R-Cards. It assumes that the reader is familiar with personal and managed I-Cards. For more information about I-Cards refer to the OASIS IMI TC and the Information Card Foundation.

At a high level I-Cards are are representations of digital identities. A card can be thought of as either containing a Digital Identity as in the case of a personal I-Card, or holding a pointer to a Digital Identity as in the case of a managed card. When imported into a Card Selector the user can "send" these (personal or managed) cards to a Relying party (RP). This has the effect of sending a security token containing claims about the Digital Identity to the RP. In this user-managed manner, the RP requests a set of claims and the user releases a matching set and conveys them to the RP.

The same process of releasing claims about a Digital Identity can be performed using an R-Card. However, if the RP requests the special "r-card" claim, called "resource-udr", and if the user consents to release, the RP will gain the value of the resource-udr claim. The resource-udr claim is different from most claims, wherein the value is a literal (e.g. a name or postal code) and can be used directly. Instead the value of the resource-udr claim is a reference. It is a pointer that can be dereferenced over the network to the Entity whose attributes define the Digital Identity of the card. The resource-udr claim references an Entity object, analogously to how a URL references an HTML document in the Web. The referenced Entity is a data object described by the Higgins Context Data Model that consists of a set of Attributes.

Dynamic values. By providing a reference to this Entity to the RP, the card issuer is creating a durable connection from the RP to the Entity such that the RP can request at any time the latest values of these attributes. Although it is true that this connection can be severed either by the user or the card issuer at any time, while it has not been severed, the RP can request the most up-to-date values of the claim.

Read/write access. The R-Card enable the RP to not only read the latest values attributes, but it may enable the RP to write some or all of these attribute values. The attribute-by-attribute permissioning is controlled by the access control policy of the card issuer. [Note: implementing this kind of fine-grained access control using declarative policy is the motivation for the Access Control in IdAS work.] By contrast, regular, non "R", cards have claim values that are read-only.

From Cards to Relationship Cards

In this section we describe the relationship between a managed card and its associated Security Token Service (STS). Using the same framework we then describe the relationship between a "relationship" managed cards (an <span style="text-decoration: underline;" />R-M-Card), its associated STS and its associated Attribute Service (AS).

M-Card and STS

Shown below is an instance of a managed card and its associated STS. The card XML contains, among other things, an endpoint reference (EPR) and a CardId string. This EPR is the network address of the card's associated STS. When the card was originally generated this EPR and CardId were written into the card XML and are immutable. As shown above the entire card can be thought of as a kind of human-friendly pointer. This pointer points to what we'll call an account object in the STS. The STS maintains a separate account for each card.

When the card is imported into a selector, and the user "sends" it to the Relying Party (RP), the selector sends a request message to this STS. This request asks for for a security token containing a set of attributes or claims. This request includes the CardId (the entire "pointer"). The STS may use any method at all to generate these claims, and they may be dependent on the claims contained in the request, and/or other external factors. But in the case of interest here, the STS is acting as a claim authority "about" the entity resented by the account. The STS retrieves claim values from this account and encodes them into the security token object that it returns.

One last point about these claims. The card itself contains a list of the types of claims it "supports." A card might support a "first name" and a "last name" claim as well as a "frequent flyer" claim. These claims define the types of the values that will be returned in the token generated by the STS. In a selector-based interaction the RP defines the set of claims (both required and optional) and the selector/user choose a card that supports these claim types. The selector then requests a token with these claims from the STS.

We have just described the basics of how all managed cards and their STSes interrelate. We now describe an STS with the same external behavior, but a different internal architecture.

M-Card and AS-based STS

Shown below is our now familiar managed card pointing to its STS as before. What's different is that this STS has delegated the storage of the account claims to a separate Attribute Service (AS). Like the STS itself, the AS is a separate web service. The account object in this design holds a network resolvable reference to an Entity in some Context managed by the AS. This reference is called an Entity UDI and is described more fully later.

This layered design has the advantage that the AS service provides an abstraction over one or more data sources and thereby provides a separation of concerns. The STS can now focus on handling the token request messages and generating tokens. It delegates to the AS the issues of access to underlying data stores. The AS provides a common API for data access across a range of alternative data sources and technologies. An AS could, for example, have a connector to an LDAP store and the STS above is shielded from knowing anything about how to access an LDAP store. This is two layer design is used by both the Higgins STS IdP and the Higgins SAML2 IdP with the exception that in both cases the "upper" STS portion directly consumes the IdAS java interfaces, as opposed to using a looser, network connection to a "real" AS web service.

With this design, when the STS receives a request for a token, it resolves the request to the account object. It resolves the Entity UDI to an Entity and its containing Context "container" and retrieves one or more attributes from the Entity. These are the values that it embeds in the security token that it generates and returns.

We're now at the end of our discussion of managed cards and we've set the stage for a discussion of how R-Cards fit into the same framework.

R-Card and AS-based STS

In the diagram below we've switched the managed card for a special kind of managed card, the R-Card. As before the entire card acts as a kind of pointer to an STS and within it an account. This is the same as before. And shown in red is the other pointer, the Entity UDI held by the account object and pointing to the Entity.

Different from a managed card, an R-Cards always supports a special claim called resource-udr. If the RP lists resource-udr as a required claim, the selector will only display cards that support this claim, i.e. R-Cards. If the RP lists this claim as optional then the user may have a choice of sending a managed or an R-Card.

We now walk through a specific scenario to illustrate how the R-Card, the STS and AS interact. Let's presume that the RP, in addition some regular claims also requires the resource-udr claim. Further, let's assume that the user clicks (and thus "sends") the R-Card that is shown below. The selector will request a token from the STS and include the resource-udr as one of the claims that must be returned in the generated token. The request will, as before, include the CardId and thus identify the card's specific account object that is to be the source of the claim values.

The STS gets the value of all of the regular claims from the Entity object in just the same way it would if it had been a managed card. What's different is how the value of the resource-udr claim is handled. Instead of retrieving the value from the Entity, it simply uses the Entity UDI as the value of the resource-udr claim.

When the RP receives the token, in validates it and then extracts the values of the claims. By returning the Entity UDI as the value of the resource-udr claim, the RP now has the network, resolvable address of the Entity. As a consequence it can attempt (at any time) to retrieve the (current) value of the attributes of this Entity. This direct data access is shown in the diagonal red line above.

We mentioned that the STS can return the Entity UDI directly. But it may instead return an inline XRD. If during the complete UDI-to-Entity resolution process the Entity UDI resolves as a first step to an XRDS document, then rather than returning the Entity UDI the STS may return the XRD section from within that XRDS document. This optional approach is useful in situations where the AS wishes (e.g. for security reasons) to keep the contents of the XRD private and only visible to authorized parties.

The resource-udr meta claim

From a file format point of view, any I-Card that supports the http://schemas.informationcard.net/@ics/resource-udr/2009-03 claim is an R-Card. See ICF Claim Catalog for more information about this claim type.

The value of the resource-udr claim is either an Entity UDI or an "inline" XRD document as would normally be found in a standalone XRDS container document.

A UDI is a string (URI, XRI, Cool URI or anything else) that somehow can be dereferenced to a Context, Entity or Attribute. In the case of an R-Card it the UDI is always an Entity UDI that can be dereferenced to an Entity in some data Context. If the value of the resource-udr is an Entity UDI then then the UDI resolution process as defined here is performed. If the RP (or any other party) wishes to use IdAS to resolve the UDI, the IdAS UDI Resolution component can be used.

If, on the other hand, the UDI value is an XRDS document, then this document provides all of the information necessary for resolve the Entity without first dereferencing an UDI to get to this document as is done as the first step in UDI resolution.

Claim and Attribute Schema

Definitions

• An R-Card inherits from its managed card basis a linear set, S1, of claim type URIs supported by the STS. The semantics of these claims are unchanged from normal managed cards: the issuer defines the maximal set of supported claims; the actual set of claims encoded in a security token is some or all of this maximal set of claims.
• The target Entity to which the R-Card's resource-udi claim points has a schema consisting of a linear set, S2, of attribute type URIs. To reduce confusion we call S2 attributes as opposed to the S1 claims
• The S2 schema may be retrieved by dereferencing the Entity UDI (e.g. using IdAS) and querying the schema of the Context containing the Entity.

Axioms

1. Every member (claim/attribute type URI) of S1 is also member of S2. [The converse isn't necessarily true. That is, S2 may be a superset of S1].
2. For any member of S2 that is also a member of S1, the data type of the value(s) of the attribute must be restricted to the set of allowed claim value types defined by the managed card specifications.
3. The data type of attributes in S2 that are not also a member of the S2 set of claims, are not limited to those defined by the managed card specifications. [For example, these S2-only attributes may have complex, structured values.]

Claim vs. Attribute values

The value(s) of a claim in S1 (as returned in a security token) is not guaranteed to be the same as the value(s) of the corresponding attribute in S2. This is due to the fact that S2 attributes are dynamic and thus may vary over time. Best practice is that at any given point in time the values SHOULD be the same.

Authentication

Because an R-Card sets up a data sharing relationship that extends outside the boundaries of the exchange of a security token associated with the card (i.e., the current managed and/or personal card functionality), this raises the question of how the RP receiving the R-Card will authenticate to the data service hosting the target entity. The issues include:

1. How does the RP discover what type of authentication materials are required? How are these types described (e.g. as a URI)?
2. What types of authentication materials should be supported?
3. How should the authentication credentials be serialized in the data sharing protocol?

RP Authentication Scheme Discovery

How the RP discovers the kind of authentication materials required depends on the type of value of the resource-udr claim. There are two possibilities. If the value is an Entity UDI then the type of authentication materials is described as a URI in the XRD of the target Context that is found during URI resolution. If, on the other hand, the value is an XRD, then the URI describing the type of authentication material required will be included in this XRD. These URIs are described in the the Authentication Material Types section of Authentication Materials.

Authentication Credential Serialization

This issue lives at two levels:

IdAS Layer

How will authentication credentials be serialized at the IdAS layer?

2009-02-26 – TODO - Markus to post a proposal.

Data Sharing Protocol Layer

How authentication data is serialized is protocol dependent. This serialization must be covered by the data sharing protocol specifications and if necessary the schema/dictionary specifications used by that protocol for the specific authentication schemes.

To use XDI as an example, the overall serialization formats for XDI are being defined in the XDI Serialization specification. Then the encoding of the specific XDI data types involved with a particular authentication scheme is specified in the XDI dictionary defining those data types. (XDI dictionaries semantics is being defined in the XDI Dictionary specification.)

Open Issues

1. Need to explore the advantages of SAML 2.0's ability to individually sign attributes --e.g. allow the STS to indicate on a per-attribute level what it is authoritative for.

Links

• Relationship Brokering With R-Cards
• http://en.wikipedia.org/wiki/I-Card -- outdated