Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "R-Card"
(→Authorization) |
(→Introduction) |
||
| Line 3: | Line 3: | ||
== Introduction == | == Introduction == | ||
| − | An [[R-Card]] is a kind of I-Card that holds a Higgins identifier, called | + | An [[R-Card]] is a kind of I-Card that holds a Higgins identifier, called an [[Entity Relation]]. This [[Entity Relation]] points to data objects called [[Entity | Entities]]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 [[ | + | The Higgins [[Identity Attribute Service]] can be used to resolve [[Entity Relation]]s into [[Entity | Entities]]. |
For more background on [[R-Card]]s see: http://en.wikipedia.org/wiki/I-Card#Relationship_card_.28aka_R-Card.29 | For more background on [[R-Card]]s see: http://en.wikipedia.org/wiki/I-Card#Relationship_card_.28aka_R-Card.29 | ||
Revision as of 00:35, 1 February 2008
Contents
About
This page provides the Higgins definition of an r-card ("relationship card"). See wikipedia I-Card for an overview of I-Cards including ISIP-M-Cards and R-Cards.
Introduction
An R-Card is a kind of I-Card that holds a Higgins identifier, called an Entity Relation. This Entity Relation points to data objects called Entitiess 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 Entity Relations into Entities.
For more background on R-Cards 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 Subjects 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
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 Digital Subject 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 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 Contexts 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:
<higgins:Relation>http://ldap.example.com/ldap.xrds#username</higgins:Relation>
RelationXRI (using XRI 2.0 syntax):
<higgins:Relation>xri://=example.name/($context)*($ldap)//username</higgins:Relation>