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"

(Access Control)
(Access Control)
Line 17: Line 17:
 
* 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
 
* 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 ==
 
== R-Card Functionality ==

Revision as of 14:56, 22 April 2008

{{#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


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