Difference between revisions of "I-Card"

Revision as of 03:45, 26 January 2008

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-Cards: Higgins Implementation Point of View

• I-Card: An object implemented and managed by an I-Card Provider plug-in
• I-Cards are the basis for user-visible I-Cards (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
• The I-Card schema is used by the Higgins I-Card Selector Service to match against the relying system’s policy requirements

More Complex Schema

• A URI I-Card may support complex attribute types (e.g. postal address) whose values contain structure
• The schema of these more complex I-Cards is accessed using getModel methods on the IContext interface

I-Card Types

• I-Cards are implemented, instantiated, managed by I-Card Providers that plug in to the I-Card Registry
• See I-Card Provider for a description of the types of I-Cards under development or planned

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

URICards

• Some I-Cards implement the IURICard interface whose salient feature is the getURI method that returns a ContextId--the identifier of a Context holding the underlying data.

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?

Links

• R-Card
• Higgins Home