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

R-Card

Revision as of 14:54, 22 April 2008 by Unnamed Poltroon (Talk) (Access Control)

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

Version

This page provides the Higgins definition of an R-Card ("relationship card") as used in Higgins 1.1.

  • 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 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-Cards 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 (i.e. definition, not instance) of Identity Attribute of the R-Card's Entity 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 reference to the issuer's STS for obtaining a security token. However unlike m-cards, an R-Card includes a second reference: a Higgins UDI of an Entity in the HGG. This UDI is written/set by the R-Card issuer.
  • An R-Card capable Selector receiving this R-Card can resolve the ContextId of the UDI (see that page for details) to discover the Context Provider configuration metadata necessary to access 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 (UDI]). 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>

Back to the top