Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "I-Card"

(→‎Supported Claims/Attributes)
(→‎I-Card: Representation in Personal Data Model)
 
(157 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
This page captures the idea of a protocol-agnostic I-Card
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 +
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 +
== Generic Definitions ==
 +
* See http://en.wikipedia.org/wiki/I-card (The page Paul started)
 +
* See http://en.wikipedia.org/wiki/Information_Card (The page Mike Jones (Microsoft) started)
 +
* For the good of the industry Paul and Mike are *trying* to converge the definitions. This involves compromises on both sides. Microsoft claims that "Information Card" is a generic term, but historically has used it to mean the two kinds of cards supported by CardSpace. Through discussion they've been updating Information Card wikipedia page to be less CardSpace-limited.
  
−
===What is an I-Card?===
+
== I-Card: Representation in Persona Data Model ==
−
* A visual metaphor for a container of information about [[Digital Subject]]s
+
−
* Cards can be offered (released to) to Relying Parties (well, technically Relying Party Agents)
+
−
* Cards are presented for selection and release by the [[ISS Web UI]] or [[ISS Client UI]]
+
−
* Cards can be acquired and managed by the Higgins [[I-Card Manager]]
+
  
−
===Appearance===
+
* See [[Persona Data Model 2.0]]
−
* Cards appear in the [[I-Card Selector Service]] (ISS) UI or the [[I-Card Manager]] UI as flat 2D rectangular regions with radius corners
+
−
* Cards are labeled with text called the (''CardName'') that is set by the card’s ''issuer'' 
+
−
* A card may have a background color or a (GIF or JPEG) background image (''CardImage'') set by the card’s issuer
+
−
* Cards that contain a single [[Digital Subject]] display in a text string in the center the most identifying information field(s) of the [[Digital Subject]] (e.g. first&last name)
+
  
−
===Signed I-Cards===
+
== I-Cards: As implemented in Higgins [[I-Card Service 1.1]] ==
−
* Signed cards encrypt and digitally sign a set of claims about a single [[Digital Subject]]  
+
* [[I-Card]]: An object implemented and managed by an [[I-Card Provider]] plug-in
−
* For signed cards the signing process (i.e. a [[Token Issuer]]) (e.g. STS) is the card issuer
+
* [[I-Card]]s are the basis for user-visible [[I-Card]]s (described previously) appear in the [[ISS Web UI]] (On Firefox, currently part of [[Higgins Browser Extension]]), [[ISS Client UI]] or the [[I-Card Manager]] UI as rectangular icons
−
* All CardSpace cards are signed [[I-Card]]s
+
* The [[I-Card]] schema is used by the Higgins [[I-Card Selector Service]] to match against the relying system’s policy requirements
  
−
===Unsigned I-Cards===
+
===I-Card Types===
−
* Unsigned cards contain and make available (statically or dynamically) [[Identity Attribute]] information about one or more [[Digital Subject]]s
+
* [[I-Card]]s are implemented, instantiated, managed by [[I-Card Provider]]s that plug in to the [[I-Card Registry]]  
−
* An example of an unsigned card with a signle [[Digital Subject]] would be a business card, vCard, etc.
+
* See [[I-Card Provider]] for a description of the types of [[I-Card]]s under development or planned
−
* The creator of an usigned card is called the ''issuer''
+
Higgins defines three [[I-Card Interface]]s. Two are required and one is optional
−
* An example of a card with multiple [[Digital Subject]]s would be an enterprise directory or social network
+
−
* Each [[Digital Subject]] contains a set of [[Identity Attribute]]s
+
−
* [[Identity Attribute]]s may be simple literals (e.g. firstName), complex (e.g. postalAddress), or represent relationships with other DSes
+
  
−
===Supported Claims/Attributes===
+
===I-Card Types: Required Interfaces===
−
* Signed cards declare the schema of the set of [[Claim]]s they support/offer
+
* All [[I-Card]]s implement the generic, base ''ICard'' interface. It includes methods to get the issuer of a card, the background image of a card, the display name of a card, the supported attribute/claim schema of the data retrieveable by the card, a way to retrieve the current value(s) of the claim(s) of the card, and so on.
−
* Unsigned cards declare the schema of the set of [[Identity Attribute]]s they support/offer
+
* All [[I-Card]]s implement the ''ITokenCard'' interface whose prominent feature is the ''getDigitalIdentity'' method that returns a signed security token that includes the claims and their values
−
* Schema format TBD (hmm.. OWL-DL would be overkill for CardSpace cards, but required for RSS-P cards)
+
  
−
===Who Creates Them?===
+
==[[I-Card]]s and the [[I-Card Registry]]==
−
* The original creator of a card is called the issuer
+
* [[I-Card]]s are implemented, instantiate and managed by plug-ins called [[I-Card Provider]]s
−
* Managed cards are cards issued by an external party (person or organization) and made available to you
+
* All [[I-Card Provider]]s must support the two required interfaces (including ''ITokenCard'')
−
* Examples of managed cards include credit cards and driver’s licenses
+
* Managed [[I-Card Provider]]s are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
−
* You can also create your own cards (and for these you are the issuer)
+
* [[I-Card Provider]]s are responsible for persistence and encryption of their I-Card instances (user can control where (e.g. on the net, in thumbdrive) each card is stored)
−
* Cards store the human-friendly name of the issuer (''IssuerName'')
+
−
* Cards also store the date and time when the card was created (''TimeIssued''). They may also store the date and time after which the card should be treated as expired and invalid (''TimeExpires'')
+
−
 
+
−
===I-Cards are really "Virtual" Containers===
+
−
* Managed cards usually don’t really contain (i.e. store) their information.
+
−
* Instead, they usually hold the metadata necessary to retrieve their contents on demand
+
−
* For example, managed CardSpace cards retrieve their Digital Identities using WS-Trust from an external Identity Provider
+
−
* Each card holds one or more endpoint references that specify from where the card information (ie. claims or attributes) should be retreived. The specific syntax of these endpoint references and the protocol used to retreive the information depends on the kind of card
+
−
 
+
−
===Who See's their Contents?===
+
−
* Each card has an Access Control List (ACL)
+
−
* The ACL is a list of URLs (or XRIs).
+
−
* Each URL is a site that has been granted access. (Each XRI is an i-card identifier)
+
−
* Each card is marked one of: (EveryTime, FirstTime, Never). As in “ask the user (EveryTime, FirstTime, or Never) before releasing this information to an external site/person” 
+
−
* Future: support regular expressions, wildcards and exceptions
+
−
 
+
−
===Who can edit them?===
+
−
* It depends on the card…
+
−
* Some cards (e.g. those issued by you) may be completely editable by you
+
−
* Some cards (e.g. a managed CardSpace card) are not editable at all by you
+
−
* Some cards (e.g. a managed RSS-P card) may have some fields that you can edit and some fields that you can’t
+
  
 
===I-Card Accessed List===
 
===I-Card Accessed List===
−
* Each card has an accessed list that provides the history of what parties have at one time or another been granted access to the card
+
* The [[I-Card Registry]] maintains an ''accessed list'' for each card that provides the history of what parties have at one time or another been granted access to the card
 
* It is list of triples:
 
* It is list of triples:
−
** Relying Party’s URL/XRI
+
** Relying Party’s URL
 
** Timestamp of first access
 
** Timestamp of first access
 
** Timestamp of most recent access
 
** Timestamp of most recent access
−
 
+
* Notes
−
===I-Card Providers and Protocols===
+
** Valery thinks that this accessed list maintenance should be an [[I-Card Provider]] responsibility
−
* I-Cards are implemented by plug-ins called I-Card Providers
+
** This ''accessed list'' history is not exported with the card when a card is exported.
−
* Different I-Card Providers use different identity exchange protocols with external systems
+
** Should the ''accessed list'' be "clearable" by the user?
−
* For example, a CardSpace provider uses the WS-Trust protocol to retrieve Digital Identities from an Identity Provider
+
** Should we be able to export an entire [[I-Card Registry]]?
−
* Support for CardSpace, RSS-P, SSFF (Screen Scrape and Form Fill), and OpenID-H are planned
+
−
 
+
−
===Static vs. Dynamic Data Flows===
+
−
* Some cards convey static, digitally signed sets of digital identity information to the relying party
+
−
* Others, e.g. RSS-P cards, engage in continuous, dynamic uni- or bi-directional exchange of information with the relying party
+
  
  
 +
== See Also ==
 +
* [[R-Card]]
  
−
==See Also==
+
[[Category:Higgins Data Model]]
−
* [[Higgins Wiki]]
+

Latest revision as of 09:17, 3 May 2010

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

Higgins logo 76Wx100H.jpg

Generic Definitions

  • See http://en.wikipedia.org/wiki/I-card (The page Paul started)
  • See http://en.wikipedia.org/wiki/Information_Card (The page Mike Jones (Microsoft) started)
  • For the good of the industry Paul and Mike are *trying* to converge the definitions. This involves compromises on both sides. Microsoft claims that "Information Card" is a generic term, but historically has used it to mean the two kinds of cards supported by CardSpace. Through discussion they've been updating Information Card wikipedia page to be less CardSpace-limited.

I-Card: Representation in Persona Data Model

I-Cards: As implemented in Higgins I-Card Service 1.1

I-Card Types

Higgins defines three I-Card Interfaces. Two are required and one is optional

I-Card Types: Required Interfaces

  • All I-Cards implement the generic, base ICard interface. It includes methods to get the issuer of a card, the background image of a card, the display name of a card, the supported attribute/claim schema of the data retrieveable by the card, a way to retrieve the current value(s) of the claim(s) of the card, and so on.
  • All I-Cards implement the ITokenCard interface whose prominent feature is the getDigitalIdentity method that returns a signed security token that includes the claims and their values

I-Cards and the I-Card Registry

  • I-Cards are implemented, instantiate and managed by plug-ins called I-Card Providers
  • All I-Card Providers must support the two required interfaces (including ITokenCard)
  • Managed I-Card Providers are responsible for interactions with external IdP/STSes and/or attribute sources (e.g. IdAS)
  • I-Card Providers are responsible for persistence and encryption of their I-Card instances (user can control where (e.g. on the net, in thumbdrive) each card is stored)

I-Card Accessed List

  • The I-Card Registry maintains an accessed list for each card that provides the history of what parties have at one time or another been granted access to the card
  • It is list of triples:
    • Relying Party’s URL
    • Timestamp of first access
    • Timestamp of most recent access
  • Notes
    • Valery thinks that this accessed list maintenance should be an I-Card Provider responsibility
    • This accessed list history is not exported with the card when a card is exported.
    • Should the accessed list be "clearable" by the user?
    • Should we be able to export an entire I-Card Registry?


See Also

Retrieved from "https://wiki.eclipse.org/index.php?title=I-Card&oldid=198966"

This page was last modified 09:17, 3 May 2010 by Paul Trevithick. Based on work by Anna Gorb, Paul Trevithick and Tom Carroll and others.

Back to the top