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.
Difference between revisions of "R-Card"
(→Authorization) |
(→Schema) |
||
| Line 4: | Line 4: | ||
| − | + | == Schema of the R-Card's referenced Digital Subject == | |
* 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 [[Digital Subject]] to which the [[R-Card]] points also has a schema. This schema is discoverable two ways: | * The schema of the [[Digital Subject]] to which the [[R-Card]] points also has a schema. This schema is discoverable two ways: | ||
| Line 10: | Line 10: | ||
*# 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 [[Digital Subject]] 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 a [[Digital Subject]] may have complex attribute types (e.g. postal address) whose values contain structure | ||
| + | |||
| + | === Authorization === | ||
| + | First generation R-Cards use the following authorization approach: | ||
| + | * Each type (definition, not instance) of [[Identity Attribute]] of the [[R-Card]]'s [[Digital Subject]] has associated authorization 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]] | ||
| + | |||
| + | ach attribute has at most one party listed as able to write/update/delete the attribute = | ||
== R-Card Functionality == | == R-Card Functionality == | ||
Revision as of 18:09, 27 January 2008
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.
Schema of the R-Card's referenced Digital Subject
- 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 Subjects 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
Authorization
First generation R-Cards use the following authorization approach:
- Each type (definition, not instance) of Identity Attribute of the R-Card's Digital Subject has associated authorization 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
ach attribute has at most one party listed as able to write/update/delete the attribute =
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>