|
|
| (114 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 provides the Higgins definition of an [[R-Card]] ("relationship card") as used in Higgins 1.1.
| + | |
| − | | + | |
| − | == Introduction ==
| + | |
| − | [[I-Card]]s are are representations of [[Digital Identity | digital identities]]. They are XML files whose format is defined by the [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi OASIS IMI] specifications. For more information about [[I-Card]]s refer to this OASIS IMI TC or to the [http://informationcard.net Information Card Foundation]. This page assumes that the reader is familiar with personal and managed [[I-Card]]s.
| + | |
| − | | + | |
| − | To review, an [[I-Card]] can be thought of at a high level as either "holding" a [[Digital Identity]] as in the case of personal [[I-Card]]s, 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.
| + | |
| − | | + | |
| − | ==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 [[M-Card]] and [[P-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 the available authentication schemes?
| + | |
| − | # What authentication schemes should be supported? How can they be extended?
| + | |
| − | # How should the authentication credentials be serialized in the data sharing protocol?
| + | |
| − | | + | |
| − | === RP Authentication Scheme Discovery ===
| + | |
| − | | + | |
| − | How the RP discovers the authentication scheme depends on the value of the resource-udr claim. There are two possibilities. If the value is an [[Entity UDI]] then the authentication scheme is described 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 authentication scheme will be included in this XRD. Each authentication scheme is described by an Authentication Scheme URI described in the next section.
| + | |
| − | | + | |
| − | === Authentication Scheme Types ===
| + | |
| − | | + | |
| − | * [[R-Card]] authentication schemes be identified with URIs just like [[M-Card]] authentication schemes.
| + | |
| − | * The set of [[R-Card]] authentication schemes is a superset of the set of defined [[M-Card]] authentication schemes.
| + | |
| − | | + | |
| − | Proposed authentication schemes:
| + | |
| − | * username and password - reuse URI from IMI spec
| + | |
| − | * p-card token - reuse URI from IMI spec
| + | |
| − | * X509 certificate - reuse URI from IMI spec
| + | |
| − | * "anonymous user" - need to define URI
| + | |
| − | * "least priviledged user" - need to define URI
| + | |
| − | * SAML2 assertion - not quite sure what this means
| + | |
| − | * SSO - for when the RP knows the user is already authenticated to the RP, so the [[R-Card]] client can reuse the same authentication token.
| + | |
| − | ** Is this an opaque access token (e.g. as is used in OAuth?). That is, is a token that the RP has received from an earlier authentication interaction with some other service that the service exposing the [[Entity]] trusts?
| + | |
| − | | + | |
| − | '''TODO''': I think it would be helpful to provide an example of where at least one of the above URI's might appear in an XRD. This would tie this section and the preceeding sections together.
| + | |
| − | | + | |
| − | === 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]]
| + | |
