|
|
(185 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
− | {{#eclipseproject:technology.higgins}} | + | {{#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 ISIP-M-Cards and [[R-Card]]s.
| + | |
− | | + | |
− | == Introduction ==
| + | |
− | An [[R-Card]] is a kind of [[I-Card]] that holds 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.29
| + | |
− | | + | |
− | == R-Card Functionality ==
| + | |
− | An [[R-Card]] offers a superset of the functionality of an ISIP-M-card as defined by the [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf MS ISIP] specification. The main difference is that with an ISIP-M-card the issuer controls 100% of the values of the claims supported by the card, whereas with an [[R-Card]] adds a "management" interface. If we consider a the security token produced by an ISIP-M-card to be generated by digitally signing some "raw" underlying data, and if we assume that the underlying data is represented as an [[Entity]] in the [[Context Data Model]], then what an [[R-Card]] allows is partial editability of some attributes of this [[Entity]] by parties other than the issuer (although as controlled by the issuer's access control policies).
| + | |
− | | + | |
− | == [[R-Card]] Schema ==
| + | |
− | * An [[R-Card]] inherits from its ISIP-M-Card basis a linear set, S1, of supported claim URIs. The semantics of these claims are unchanged from normal ISIP-M-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 [[Entity]] to which the [[R-Card]] points also has a schema also consisting of a linear set, S2, of claim/attribute type URIs.
| + | |
− | * For those claims common to S1 and S2, the data type of the claim must be limited to what is supported in ISIP-M-Cards. For these common claims, the [[R-Card]]'s [[Entity UDI]] (see below) can be used to resolve the data underlying these claims an in some cases (as controlled by the issuer) edit these values
| + | |
− | * Claims that exist in S2 but not S1 are never represented in security tokens generated by the issuer.
| + | |
− | * The data type of claims that exist only in S2 are not limited to those defined by ISIP-M-Cards. These S2-only claim values may be complex, structured objects.
| + | |
− | * The S2 schema may be retrieved dynamically by dereferencing the [[Entity UDI]] (e.g. using [[IdAS]]) and querying the resulting [[Entity]] as to its schema.
| + | |
− | | + | |
− | == XML Format ==
| + | |
− | An R-Card is an extention of the ISIP-M-Card XML Schema. It adds a single XML element, '''higgins:r.card.target''' whose content is an [[Entity UDI]]. This [[Entity UDI]] is written/set once by the [[R-Card]] issuer and never changes.
| + | |
− | | + | |
− | Following are examples of this element:
| + | |
− | | + | |
− | URI form:
| + | |
− | <pre>
| + | |
− | <higgins:r.card.target>http://ldap.example.com/ldap.xrds#username</higgins:r.card.target>
| + | |
− | </pre>
| + | |
− | | + | |
− | XRI form (using XRI 2.0 syntax):
| + | |
− | <pre>
| + | |
− | <higgins:r.card.target>xri://=example.name/($context)*($ldap)//username</higgins:r.card.target>
| + | |
− | </pre>
| + | |
− | | + | |
− | [[Category:Higgins Concepts]]
| + | |