|
|
| (86 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} | | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} |
| | [[Image:Higgins_logo_76Wx100H.jpg|right]] | | [[Image:Higgins_logo_76Wx100H.jpg|right]] |
| − | == Version ==
| + | See http://www.eclipse.org/higgins/documents/relationship-cards.html |
| − | This page defines a Higgins [[R-Card]] ("relationship card") as implemented in Higgins 1.1.
| + | |
| − | | + | |
| − | == Introduction ==
| + | |
| − | This section provides an introduction to [[R-Card]]s. It assumes that the reader is familiar with personal and managed [[I-Card]]s. For more information about [[I-Card]]s refer to the [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi OASIS IMI TC] and the [http://informationcard.net Information Card Foundation].
| + | |
| − | | + | |
| − | At a high level [[I-Card]]s are are representations of [[Digital Identity | 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 isn't treated as a regular claim; It's treated as a kind of "meta" claim.
| + | |
| − | | + | |
| − | The value of this meta claim is a "pointer" to an [[Entity]] associated with the [[Digital Identity]] of the card. An [[Entity]] is a data object described by the Higgins [[Context Data Model]] that has a set of [[Attribute]]s. The values of the attributes of this Entity are the same, at least initially, as the values of the claims being made about the digital identity. This meta claim references an [[Entity]] object, analogously to how a URL references an HTML document in the Web.
| + | |
| − | | + | |
| − | '''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 Managed 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 then describe the relationship between an [[R-Card]] and its associated STS and its associated Identity Data Service (IDS).
| + | |
| − | | + | |
| − | === 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.
| + | |
| − | | + | |
| − | [[Image:R-cards-p1.png|center]]
| + | |
| − | | + | |
| − | 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 IDS-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 Identity Data Service (IDS). Like the STS itself, the IDS 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 IDS. This reference is called an [[Entity UDI]] and is described more fully later.
| + | |
| − | | + | |
| − | [[Image:R-card-p2.png|center]]
| + | |
| − | | + | |
| − | This layered design has the advantage that the IDS 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 IDS the issues of access to underlying data stores. The IDS provides a common API for data access across a range of alternative data sources and technologies. An IDS 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" IDS 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-Card]]s fit into the same framework.
| + | |
| − | | + | |
| − | === R-Card and IDS-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.
| + | |
| − | | + | |
| − | [[Image:R-card-p3-v2.png|center]]
| + | |
| − | | + | |
| − | Different from a managed card, an [[R-Card]]s 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-Card]]s. 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 IDS 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 the 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 IDS 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 [https://wiki.informationcard.net/index.php/Claim_Catalog#2009 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 [http://en.wikipedia.org/wiki/XRDS 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 [http://www.azigo.com/company/dev/udi/ 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===
| + | |
| − | # 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].
| + | |
| − | # 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.
| + | |
| − | # 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:
| + | |
| − | | + | |
| − | # How does the RP discover what type of authentication materials are required? How are these types described (e.g. as a URI)?
| + | |
| − | # What types of authentication materials should be supported?
| + | |
| − | # 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 ==
| + | |
| − | # 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
| + | |
| − | | + | |
| − | [[Category:Higgins Concepts]]
| + | |
