Skip to main content
Jump to: navigation, search

Difference between revisions of "R-Card"

(R-Card Functionality)
(+ authentication section)
Line 11: Line 11:
  
 
== R-Card Functionality ==
 
== R-Card Functionality ==
An [[R-Card]] offers a superset of the functionality of an managed card as defined by the ''Identity-Selector-Interop-Profile-v1.5.pdf'' specification that can be downloaded from [http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en here]. As with an managed card, the token service referred to by the card is responsible for generating the security token, and is thus the agent that sets the values of these claims. This token service generates the claim values in the token based on some underlying attribute values. [[R-Card]]s, in addition to holding the token service endpoint reference, also hold an [[Entity UDI]] reference that "points" to a data object that holds one or more of these underlying attribute values. The agent holding an [[R-Card]] may be able to edit the values of these underlying attributes. The ability to edit these attributes is subject to the access control policy of the data service holding and managing the underlying [[Entity]] and its attributes.
+
An [[R-Card]] offers a superset of the functionality of a managed card as defined by the [http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en Identity Selector Interop Profile v1.5] (link is to a page where the PDF can be downloaded).  
 +
 
 +
As with a managed card, the token service referred to by an r-card is responsible for generating the security token, and is thus the agent that sets the values of these claims. This token service generates the claim values in the token based on some underlying attribute values. [[R-Card]]s, in addition to holding the token service endpoint reference, also hold an [[Entity UDI]] reference that "points" to a data object that holds one or more of these underlying attribute values. The agent holding an [[R-Card]] may be able to edit the values of these underlying attributes. The ability to edit these attributes is subject to the access control policy of the data service holding and managing the underlying [[Entity]] and its attributes.
  
 
== Claim Schema ==
 
== Claim Schema ==
 
* An [[R-Card]] inherits from its managed card basis a linear set, S1, of supported claim URIs. The semantics of these claims are unchanged from normal managed 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 maximal set of claims.
 
* An [[R-Card]] inherits from its managed card basis a linear set, S1, of supported claim URIs. The semantics of these claims are unchanged from normal managed 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 maximal set of claims.
 
* The [[Entity]] to which the [[R-Card]] points also has a schema also consisting of a linear set, S2, of claim/attribute type URIs.
 
* The [[Entity]] to which the [[R-Card]] points also has a schema also consisting of a linear set, S2, of claim/attribute type URIs.
* For those claims common to S1 and S2, the data type of the claim must be limited to what is supported in managed cards. For these common claims, the [[R-Card]]'s [[Entity UDI]] (see below) can be used to resolve the data underlying these claims an in some cases (as controlled by the issuer) edit these values
+
* For those claims common to S1 and S2, the data type of the claim must be limited to what is supported in managed cards. For these common claims, the [[R-Card]]'s [[Entity UDI]] (see below) can be used to resolve the data underlying these claims – and, in some cases, to edit these values as permitted by the data authority.
 
* Claims that exist in S2 but not S1 are never represented in security tokens generated by the issuer.
 
* Claims that exist in S2 but not S1 are never represented in security tokens generated by the issuer.
 
* The data type of claims that exist only in S2 are not limited to those defined by managed cards. These S2-only claim values may be complex, structured objects.
 
* The data type of claims that exist only in S2 are not limited to those defined by managed cards. These S2-only claim values may be complex, structured objects.
Line 22: Line 24:
  
 
== XML Format ==
 
== XML Format ==
An R-Card is an extention of the managed card XML Schema. It adds a single XML element, '''r.card.target''' whose content is an [[Entity UDI]]. The r.card.target element must occur within the <ic:InformationCard> scope where ic is defined as XXXX.  
+
An R-Card is an extension of the managed card XML Schema. It adds a single XML element, '''r.card.target''' whose content is an [[Entity UDI]]. The r.card.target element must occur within the <ic:InformationCard> scope where ic is defined as XXXX (''TODO – insert reference'').
  
 
This [[Entity UDI]] is written/set once by the [[R-Card]] issuer and never changes.
 
This [[Entity UDI]] is written/set once by the [[R-Card]] issuer and never changes.
Line 38: Line 40:
 
<higgins:r.card.target>xri://=example.name/($context)*($ldap)//username</higgins:r.card.target>
 
<higgins:r.card.target>xri://=example.name/($context)*($ldap)//username</higgins:r.card.target>
 
</pre>
 
</pre>
 +
 +
== Authentication ==
 +
Because an [[R-Card]] sets up a data sharing relationship that extends outside the boundaries of the exchange of a security token associated with the card (i.e., the current [[M-Card]] functionality), this raises the question of how the RP receiving the [[R-Card]] will authenticate to the data service hosting the target entity. The issues include:
 +
 +
# How does the RP discover the available authentication schemes?
 +
# What authentication schemes should be supported? How can they be extended?
 +
# How should the authentication credentials be serialized in the data sharing protocol?
 +
 +
=== Authentication Method Discovery ===
 +
The options under discussion include:
 +
# Specifying the method(s) with an additional element directly in the [[R-Card]] XML.
 +
# Specifying the methods(s) within an XRD included as the value of an XRD:
 +
## Within the [[R-Card]] XML.
 +
## As a claim within the [[R-Card]] claim payload.
 +
# Discovering the methods via UDI resolution to an XRDS document.
 +
 +
=== Authentication Scheme Types ===
 +
Just as an [[R-Card]] is a superset of an [[M-Card]], the proposal is that:
 +
# [[R-Card]] authentication schemes be identified with URIs just like [[M-Card]] authentication schemes.
 +
# [[R-Card]] authentication schemes be a superset of [[M-Card]] authentication schemes.
 +
## One new option in this superset is to use an [[M-Card]], especially because the [[R-Card]] functions as an [[M-Card]].
 +
## Other options proposed include:
 +
### "anonymous user"
 +
### "least priviledged user"
 +
### username and password
 +
### SAML2 assertion
 +
### p-card token
 +
### X509 certificate
 +
### SSO (for when the RP knows the user is already authenticated to the RP, so the [[R-Card]] client can reuse the same authentication token)
 +
 +
=== Authentication Credential Serialization ===
 +
This issue lives at two levels:
 +
 +
==== IdAS Layer ====
 +
How will authentication credentials be serialized at the IdAS layer?
 +
 +
''2009-02-26 – TODO - Markus to post a proposal.''
 +
 +
==== Data Sharing Protocol Layer ====
 +
How will authentication credentials be serialized in the data sharing protocol used to access the Entity UDI?
 +
 +
''2009-02-26 – proposal from Drummond:''
 +
 +
This should be covered by the data sharing protocol specifications and if necessary the schema/dictionary specifications used by that protocol for the specific authentication schemes.
 +
 +
To use XDI as an example, the overall serialization formats for XDI are being defined in the XDI Serialization specification. Then the encoding of the specific XDI data types involved with a particular authentication scheme is specified in the XDI dictionary defining those data types. (XDI dictionaries semantics is being defined in the XDI Dictionary specification.)
  
 
== Open Issues ==
 
== Open Issues ==
 
# Is the value of a claim in S1 the same as the value of the corresponding attribute/claim in S2?
 
# Is the value of a claim in S1 the same as the value of the corresponding attribute/claim in S2?
 
#* Tentative answer: Sameness is not guaranteed
 
#* Tentative answer: Sameness is not guaranteed
# Is there a need to define how the UDI (perhaps as signed by the STS, etc.) is passed within the RST message.
+
# Is there a need to define how the UDI (perhaps as signed by the STS, etc.) is passed within the RST message?
# Need to explore the advantages of SAML 2.0's ability to individually sign attributes --e.g. allow the STS to indicate on a per attribute level what they are authoritative for
+
# Need to explore the advantages of SAML 2.0's ability to individually sign attributes --e.g. allow the STS to indicate on a per-attribute level what it is authoritative for.
  
 
== Links ==
 
== Links ==

Revision as of 05:19, 26 February 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

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 managed cards and R-Cards.

Introduction

An R-Card is a kind of I-Card that holds an Entity UDI as described by the Context Data Model. This Entity UDI references an Entity object, analogously to how a URL references an HTML document in the Web.

For more background on R-Cards see: http://en.wikipedia.org/wiki/I-Card#Relationship_card_.28aka_R-Card.29

R-Card Functionality

An R-Card offers a superset of the functionality of a managed card as defined by the Identity Selector Interop Profile v1.5 (link is to a page where the PDF can be downloaded).

As with a managed card, the token service referred to by an r-card is responsible for generating the security token, and is thus the agent that sets the values of these claims. This token service generates the claim values in the token based on some underlying attribute values. R-Cards, in addition to holding the token service endpoint reference, also hold an Entity UDI reference that "points" to a data object that holds one or more of these underlying attribute values. The agent holding an R-Card may be able to edit the values of these underlying attributes. The ability to edit these attributes is subject to the access control policy of the data service holding and managing the underlying Entity and its attributes.

Claim Schema

  • An R-Card inherits from its managed card basis a linear set, S1, of supported claim URIs. The semantics of these claims are unchanged from normal managed 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 maximal set of claims.
  • The Entity to which the R-Card points also has a schema also consisting of a linear set, S2, of claim/attribute type URIs.
  • For those claims common to S1 and S2, the data type of the claim must be limited to what is supported in managed cards. For these common claims, the R-Card's Entity UDI (see below) can be used to resolve the data underlying these claims – and, in some cases, to edit these values as permitted by the data authority.
  • Claims that exist in S2 but not S1 are never represented in security tokens generated by the issuer.
  • The data type of claims that exist only in S2 are not limited to those defined by managed cards. These S2-only claim values may be complex, structured objects.
  • The S2 schema may be retrieved dynamically by dereferencing the Entity UDI (e.g. using IdAS) and querying the resulting Entity as to its schema.

XML Format

An R-Card is an extension of the managed card XML Schema. It adds a single XML element, r.card.target whose content is an Entity UDI. The r.card.target element must occur within the <ic:InformationCard> scope where ic is defined as XXXX (TODO – insert reference).

This Entity UDI is written/set once by the R-Card issuer and never changes.

Following are examples of this element:

URI form:

<higgins:r.card.target>http://ldap.example.com/ldap.xrds#username</higgins:r.card.target>


XRI form (using XRI 2.0 syntax):

<higgins:r.card.target>xri://=example.name/($context)*($ldap)//username</higgins:r.card.target>

Authentication

Because an R-Card sets up a data sharing relationship that extends outside the boundaries of the exchange of a security token associated with the card (i.e., the current M-Card functionality), this raises the question of how the RP receiving the R-Card will authenticate to the data service hosting the target entity. The issues include:

  1. How does the RP discover the available authentication schemes?
  2. What authentication schemes should be supported? How can they be extended?
  3. How should the authentication credentials be serialized in the data sharing protocol?

Authentication Method Discovery

The options under discussion include:

  1. Specifying the method(s) with an additional element directly in the R-Card XML.
  2. Specifying the methods(s) within an XRD included as the value of an XRD:
    1. Within the R-Card XML.
    2. As a claim within the R-Card claim payload.
  3. Discovering the methods via UDI resolution to an XRDS document.

Authentication Scheme Types

Just as an R-Card is a superset of an M-Card, the proposal is that:

  1. R-Card authentication schemes be identified with URIs just like M-Card authentication schemes.
  2. R-Card authentication schemes be a superset of M-Card authentication schemes.
    1. One new option in this superset is to use an M-Card, especially because the R-Card functions as an M-Card.
    2. Other options proposed include:
      1. "anonymous user"
      2. "least priviledged user"
      3. username and password
      4. SAML2 assertion
      5. p-card token
      6. X509 certificate
      7. SSO (for when the RP knows the user is already authenticated to the RP, so the R-Card client can reuse the same authentication token)

Authentication Credential Serialization

This issue lives at two levels:

IdAS Layer

How will authentication credentials be serialized at the IdAS layer?

2009-02-26 – TODO - Markus to post a proposal.

Data Sharing Protocol Layer

How will authentication credentials be serialized in the data sharing protocol used to access the Entity UDI?

2009-02-26 – proposal from Drummond:

This should be covered by the data sharing protocol specifications and if necessary the schema/dictionary specifications used by that protocol for the specific authentication schemes.

To use XDI as an example, the overall serialization formats for XDI are being defined in the XDI Serialization specification. Then the encoding of the specific XDI data types involved with a particular authentication scheme is specified in the XDI dictionary defining those data types. (XDI dictionaries semantics is being defined in the XDI Dictionary specification.)

Open Issues

  1. Is the value of a claim in S1 the same as the value of the corresponding attribute/claim in S2?
    • Tentative answer: Sameness is not guaranteed
  2. Is there a need to define how the UDI (perhaps as signed by the STS, etc.) is passed within the RST message?
  3. Need to explore the advantages of SAML 2.0's ability to individually sign attributes --e.g. allow the STS to indicate on a per-attribute level what it is authoritative for.

Links

Copyright © Eclipse Foundation, Inc. All Rights Reserved.