Difference between revisions of "R-Card"

Revision as of 14:44, 3 February 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.

Introduction

An R-Card is a kind of I-Card that holds a Higgins identifier, called an I-Node Relation. This I-Node 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 I-Node Relations into I-Nodes.

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 I-Node

• 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 I-Node 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 I-Nodes 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 I-Node 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 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 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

• Higgins Home
• Concepts