|
|
(192 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 a [[UDI]] that references an [[Entity]] in the [[Higgins Global Graph]], in much the same way that a URL is a reference to an HTML document in the Web.
| + | |
− | | + | |
− | The Higgins [[Identity Attribute Service]] can be used to resolve an [[Entity]] [[UDI]] into an [[Entity]].
| + | |
− | | + | |
− | 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 [[Entity]] ==
| + | |
− | * 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 [[Entity]] to which the [[R-Card]] points also has a schema. [[IdAS]] can resolve the [[R-Card]]'s [[UDI]] into an [[Entity]], lookup it's [[Context]] and retrieve that [[Context]]'s schema/ontology
| + | |
− | * Unlike an ISIP-M-Card whose "supported claim" type URIs may only have zero or more simple, string-typed values, the URI's of an [[Entity]] may have complex attribute types (e.g. postal address) whose values contain structure
| + | |
− | | + | |
− | == Access Control ==
| + | |
− | First generation R-Cards use the following access control approach:
| + | |
− | * Each type (definition, not instance) of [[Identity Attribute]] of the [[R-Card]]'s [[I-Node]] has associated access control 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]]
| + | |
− | * Query requests to this access control metadata is handled in a special manner. First, what can be seen depends who authenticated to the [[Context]]. Second, instead of returning the values of editableBy, all that is returned is a boolean as to whether the currently-authenticated identity who has opened the [[Context]] is listed in the list of values of "editableBy". Third, the client of IdAS must authenticate AS one of the DSes in the [[Context]]. [Note you can auth as a "role" or "group" or as a regular "person" DS. And the values of editableBy may include "role", "group" or "person" relations (identifiers) as values.
| + | |
− | | + | |
− | == 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 [[I-Node]] to which the r-card applies. This relation is provisioned by the r-card issuer, and points to the [[I-Node]] 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>
| + | |
− | | + | |
− | [[Category:Higgins Concepts]]
| + | |