|
|
| (139 intermediate revisions by the same user 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 ==
| + | |
| − | An [[R-Card]] is a specialization of a managed [[I-Card]] that has one special "meta" claim of http://schemas.informationcard.net/@ics/resource-udr/2009-03 (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]] as described by the [[Context Data Model]]. This [[Entity UDI]] references an [[Entity]] object, analogously to how a URL references an HTML document in the Web. The
| + | |
| − | * an "inline" XRDS document
| + | |
| − | | + | |
| − | == An R-Card is a kind of Infocard ==
| + | |
| − | These [[R-Card]] specifications can be thought of as a profile (that is, a documented convention on a special way to use) a ''managed'' or ''personal'' Information Card as defined by [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi OASIS IMI].
| + | |
| − | | + | |
| − | In a sense a regular managed card returns claim values "by value." You can think of an [[R-Card]] as having the ability to return values both "by value" and "by reference."
| + | |
| − | | + | |
| − | As with any managed card, the token service referred to by an [[R-Card]] is responsible for generating the security token and thereby setting the values of these claims contained therein. An [[R-Card]] supports an additional "meta" claim (the resource-udi claim mentioned above) the value of which is a reference to a service that exposes a data object (called an [[Entity]]) in a data context (called a [[Context]]). This Entity object has a set of attributes. The ability to read (and potentially write) these attributes is subject to the access control policy of the data service holding and managing the [[Entity]].
| + | |
| − | | + | |
| − | == 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]] 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?
| + | |
| − | | + | |
| − | === Authentication Scheme Discovery ===
| + | |
| − | The options under discussion include:
| + | |
| − | # Specifying the scheme(s) with an additional element directly in the [[R-Card]] XML.
| + | |
| − | # Specifying the schemes(s) using an XRD (which itself is an XML document) that is included within the [[R-Card]] itself. The options for including it are:
| + | |
| − | ## Include it within the [[R-Card]] XML the same way as the r-card target.
| + | |
| − | ## As a claim within the [[R-Card]] claim payload. A possible downside is that if there is no STS involved, there is no source for this claim. On the 2009-02-26 Higgins telecon, it was discussed that perhaps [[R-Card]]s should require an STS, which would eliminate this concern.
| + | |
| − | # Discovering the methods via UDI resolution to an XRDS document. This requires that the target Higgins [[Context]] has an XRD that describes it.
| + | |
| − | | + | |
| − | === Authentication Scheme Types ===
| + | |
| − | Just as an [[R-Card]] is a superset of an [[M-Card]], the proposal is that:
| + | |
| − | # [[R-Card]] authentication schemes be identified with URIs just like [[M-Card]] authentication schemes.
| + | |
| − | # [[R-Card]] authentication schemes be a superset of [[M-Card]] authentication schemes.
| + | |
| − | ## One new option in this superset is to use an [[M-Card]], especially because the [[R-Card]] functions as an [[M-Card]].
| + | |
| − | ## Other options proposed include:
| + | |
| − | ### "anonymous user"
| + | |
| − | ### "least priviledged user"
| + | |
| − | ### username and password
| + | |
| − | ### SAML2 assertion
| + | |
| − | ### p-card token
| + | |
| − | ### X509 certificate
| + | |
| − | ### 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)
| + | |
| − | | + | |
| − | === 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 will authentication credentials be serialized in the data sharing protocol used to access the Entity UDI?
| + | |
| − | | + | |
| − | ''2009-02-26 – proposal from Drummond:''
| + | |
| − | | + | |
| − | This should 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]]
| + | |
