Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "R-Card"

(See Also)
(About)
Line 1: Line 1:
 
== About ==
 
== About ==
 
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.
 
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.
 +
 +
=== Authorization ===
 +
 +
=== Schema ===
 +
* 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
  
 
== R-Card Functionality ==
 
== R-Card Functionality ==

Revision as of 18:00, 27 January 2008

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.

Authorization

Schema

  • 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:
    1. 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.
    2. 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

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>

See Also

Back to the top