Skip to main content
Jump to: navigation, search

Difference between revisions of "R-Card"

(XML Format)
 
(168 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]
== Version ==
+
See http://www.eclipse.org/higgins/documents/relationship-cards.html
This page provides the Higgins definition of an [[R-Card]] ("relationship card") as used in Higgins 1.1.
+
* See wikipedia [http://en.wikipedia.org/wiki/I-Card I-Card] for an overview of I-Cards including managed cards and [[R-Card]]s.
+
 
+
== 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-Card]]s 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 an ISIP-M-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 ISIP-M-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.
+
 
+
== 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 an in some cases (as controlled by the issuer) edit these values
+
* 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 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.
+
 
+
This [[Entity UDI]] is written/set once by the [[R-Card]] issuer and never changes.
+
 
+
Following are examples of this element:
+
 
+
URI form:
+
<pre>
+
<higgins:r.card.target>http://ldap.example.com/ldap.xrds#username</higgins:r.card.target>
+
</pre>
+
 
+
 
+
XRI form (using XRI 2.0 syntax):
+
<pre>
+
<higgins:r.card.target>xri://=example.name/($context)*($ldap)//username</higgins:r.card.target>
+
</pre>
+
 
+
== Open Issues ==
+
# 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
+
# 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
+
 
+
== Links ==
+
* [[I-Card]]
+
 
+
[[Category:Higgins Concepts]]
+

Latest revision as of 19:40, 18 July 2011

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

Higgins logo 76Wx100H.jpg

See http://www.eclipse.org/higgins/documents/relationship-cards.html

Back to the top