Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "R-Card"
m (logo, category) |
|||
| Line 5: | Line 5: | ||
== Introduction == | == Introduction == | ||
| − | An [[R-Card]] is a kind of I-Card that holds a Higgins identifier, called an [[I- | + | An [[R-Card]] is a kind of I-Card that holds a Higgins identifier, called an [[I-Entity Relation]]. This [[I-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 [[I- | + | The Higgins [[Identity Attribute Service]] can be used to resolve [[I-Entity Relation]]s into [[I-Entity]]s. |
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 | ||
| − | == Schema of the R-Card's referenced [[I- | + | == Schema of the R-Card's referenced [[I-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 [[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- | + | * The schema of the [[I-Entity]] 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 [[I- | + | *# 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-Entity]]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]] | *# 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- | + | * 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-Entity]] may have complex attribute types (e.g. postal address) whose values contain structure |
== Access Control == | == Access Control == | ||
First generation R-Cards use the following access control approach: | First generation R-Cards use the following access control approach: | ||
| − | * Each type (definition, not instance) of [[Identity Attribute]] of the [[R-Card]]'s [[I- | + | * Each type (definition, not instance) of [[Identity Attribute]] of the [[R-Card]]'s [[I-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]] | ** 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. | * 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. | ||
| Line 27: | Line 27: | ||
An r-card is a superset of the functionality of an ISIP-M-card as defined by the [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf MS ISIP] specification. The differences are: | An r-card is a superset of the functionality of an ISIP-M-card as defined by the [http://download.microsoft.com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1.pdf 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- | + | * 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-Entity]] to which the r-card applies. This relation is provisioned by the r-card issuer, and points to the [[I-Entity]] 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. | * 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 [[Context]]s specifically designed for generalized cross-domain data sharing such as [[XDI]]. | * 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 [[Context]]s specifically designed for generalized cross-domain data sharing such as [[XDI]]. | ||
Revision as of 06:00, 11 April 2008
{{#eclipseproject:technology.higgins}}
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 I-Entity Relation. This I-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 I-Entity Relations into I-Entitys.
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-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 I-Entity to which the R-Card points also has a schema. This schema is discoverable two ways:
- 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-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 (definition, not instance) of Identity Attribute of the R-Card's I-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 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-Entity to which the r-card applies. This relation is provisioned by the r-card issuer, and points to the I-Entity 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>