|
|
(206 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
− | == About ==
| + | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} |
− | This page provides the Higgins definition of an '''r-card''' ("relationship card"). See wikipedia [http://en.wikipedia.org/wiki/I-Card I-Card] for an overview of I-Cards including ISIP-M-Cards and R-Cards.
| + | [[Image:Higgins_logo_76Wx100H.jpg|right]] |
− | | + | See http://www.eclipse.org/higgins/documents/relationship-cards.html |
− | == Introduction ==
| + | |
− | An [[R-Card]] is a kind of I-Card that holds a Higgins identifier, called a [[Relation]]. This [[Relation]] points to data objects called [[Digital Subject]]s in the [[Higgins Global Graph]] in much the same way a URL points to an HTML document in the Web.
| + | |
− | | + | |
− | The Higgins [[Identity Attribute Service]] can be used to resolve [[Relation]]s into [[Digital Subject]]s.
| + | |
− | | + | |
− | For more background on [[R-Card]]s see: http://en.wikipedia.org/wiki/I-Card#Relationship_card_.28aka_R-Card.29
| + | |
− | | + | |
− | == Schema of the R-Card's referenced Digital Subject ==
| + | |
− | * The [[R-Card]] inherits a linear list of supported claim URIs of the ISIP-M-Card fields. The semantics of these 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 set of claims.
| + | |
− | * The schema of the [[Digital Subject]] to which the [[R-Card]] points also has a schema. This schema is discoverable two ways:
| + | |
− | *# The IdAS can resolve the [[R-Card]]'s [[Relation]]'s [[ContextId]] into a [[Context]] instance. IdAS provides interfaces to inspect the schema of the [[Context]] and the [[Digital Subject]]s which it contains.
| + | |
− | *# It can be looked up within the <TBD> element in the [[Higgins XRDS Service Endpoint]] of the [[Relation]] stored in the [[R-Card]]
| + | |
− | * Unlike an ISIP-M-Card whose "supported claim" type URIs may only have zero or more simple, string-typed values, the URI's of a [[Digital Subject]] may have complex attribute types (e.g. postal address) whose values contain structure
| + | |
− | | + | |
− | == Authorization ==
| + | |
− | First generation R-Cards use the following authorization approach:
| + | |
− | * Each type (definition, not instance) of [[Identity Attribute]] of the [[R-Card]]'s [[Digital Subject]] has associated authorization metadata that indicates what identity (or identities) may edit or delete this attribute and/or add new instances of this attribute. Read authorization is universal (with the exception of special authentication credential attribute types).
| + | |
− | ** Specifically, each higgins:simpleAttribute or higgins:complexAttribute has an "attributeMetatdata" predicate to instance of higgins:AttributeMetadata. This latter instance in turn has zero or more "editableBy" (or "deleteableBy" or "addableBy") predicates whose (URI literal) values indicate an identity authorized to edit instances of this [[Identity Attribute]]
| + | |
− | | + | |
− | == R-Card Functionality ==
| + | |
− | An r-card is 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 differences are:
| + | |
− | | + | |
− | * Both r-cards and m-cards include a pointer to the issuer's STS for obtaining a security token, but an r-card includes a '''second''' pointer: a Higgins [[Relation]] to the [[Digital Subject]] to which the r-card applies. This relation is provisioned by the r-card issuer, and points to the [[Digital Subject]] in the [[Context]] designated by the issuer.
| + | |
− | * An r-card capable [[Selector]] receiving this r-card can resolve the [[ContextId]] of the [[Relation]] (see that page for details) to discover the [[Context Provider]] configuration metadata necessary to communicate with this context.
| + | |
− | * R-card data sharing relationships will work with any [[Context]] to which the [[Selector]] accepting the r-card can speak. For the greatest interoperability, r-card issuers can use [[Context]]s specifically designed for generalized cross-domain data sharing such as [[XDI]].
| + | |
− | | + | |
− | == XML Format ==
| + | |
− | An R-Card requires an extension to the ISIP-M-Card XML Schema. It adds a single XML element, '''higgins:Relation''' whose content is a string (URI). Following are examples of such an element:
| + | |
− | | + | |
− | RelationURI:
| + | |
− | <pre>
| + | |
− | <higgins:Relation>http://ldap.example.com/ldap.xrds#username</higgins:Relation>
| + | |
− | </pre>
| + | |
− | | + | |
− | RelationXRI (using XRI 2.0 syntax):
| + | |
− | <pre>
| + | |
− | <higgins:Relation>xri://=example.name/($context)*($ldap)//username</higgins:Relation>
| + | |
− | </pre>
| + | |
− | | + | |
− | == See Also ==
| + | |
− | * [http://eclipse.org/higgins Higgins Home]
| + | |
− | * [[Concepts]]
| + | |