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 "I-Card vocabulary"
(→P-Card Attributes) |
|||
| Line 35: | Line 35: | ||
== P-Card Attributes == | == P-Card Attributes == | ||
| − | The attributes that define a personal card are taken directly from the OASIS IMI specification. An example p-card | + | The attributes that define a personal card are taken directly from the OASIS IMI specification. |
| + | |||
| + | === An example p-card === | ||
[[Image:Personal-i-card-example.png|center]] | [[Image:Personal-i-card-example.png|center]] | ||
Revision as of 23:44, 13 October 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Information card represented in OWL. See also I-Card.
Information Card (aka i-card) technology is defined by the OASIS IMI TC. It is a standard way to represent a person's digital identities using a card metaphor, XML card formats, and associated SOAP and HTTP network protocols. See also I-Card.
Before we introduce the I-Card classes, remember that in CDM multiple inheritance is allowed: any single entity may be a member of multiple classes simultaneously.
Contents
Files
UML Overview
Classes
I-Card
Abstract class
- subclassOf:
h:Context. - 1..1
cardId (xsd:string)- a unique identifier for the card - 1..1
image- an image bitmap for the background of the card when it is displayed - ... others.
P-Card
An OASIS IMI Personal card
- subclassOf:
I-Card
M-Card
An OASIS IMI Managed card
- subclassOf:
I-Card
P-Card Attributes
The attributes that define a personal card are taken directly from the OASIS IMI specification.
An example p-card
ERRATA: context object entity id should be _ContextSingleton
M-Card Attributes
Shown below is an example of an instance of an m-card. For simplicity this m-card has only a single supported claim, "LastName". The entity shown in the center of the card is a cache of what is returned by the STS in response to a request for a display token.
Note: There is an error in the above diagram the DisplayTokenEntity should have been modeled in the Persona data model (thus identity:surname would have been transformed into its equivalent in PDM.
Card Axioms
- For any M-Card: The value of any of the above "supported" claims attributes is considered to be a cache of the most recent value of these claims as fetched from the m-card's STS