|
|
| (148 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.
| + | |
| − | * See wikipedia [http://en.wikipedia.org/wiki/I-Card I-Card] for an overview of I-Cards including managed cards and [[R-Card]]s.
| + | |
| − | | + | |
| − | == 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-udi/2009-3 (see [https://wiki.informationcard.net/index.php/Claim_Catalog#2009] for more information about this claim type).
| + | |
| − | | + | |
| − | The value of the resource-udi claim is 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.
| + | |
| − | | + | |
| − | For more background on [[R-Card]]s see: http://en.wikipedia.org/wiki/I-Card#Relationship_card_.28aka_R-Card.2 <-- needs updating
| + | |
| − | | + | |
| − | == R-Card Functionality ==
| + | |
| − | An [[R-Card]] offers a superset of the functionality of a managed card as defined by the [http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en Identity Selector Interop Profile v1.5 (PDF)] (soon to be superceded by the OASIS IMI TC's initial output).
| + | |
| − | | + | |
| − | In a sense a regular managed card returns claim values "by value." You can think of an [[R-Card]] as, in addition, returning values "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.]
| + | |
| − | | + | |
| − | == 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 ==
| + | |
| − | # Is the value of a claim in S1 the same as the value of the corresponding attribute/claim in S2?
| + | |
| − | #* Tentative answer: Sameness is not guaranteed
| + | |
| − | # We need to define a claim type URI for the resource.udi claim when it is a supported claim type of the [managed portion of the] r-card
| + | |
| − | # 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]]
| + | |
| − | | + | |
| − | [[Category:Higgins Concepts]]
| + | |
