Difference between revisions of "I-Card Provider"

Revision as of 02:27, 16 November 2006

Overview

• An I-Card Provider is responsible for instantiating and managing I-Card instances (that implement the I-Card Interfaces)
• A Provider is also responsible for importing I-Cards from serialized data formats. For example a CardSpace I-Card Provider would be responsible for being able to import CardSpace format data files.
• A Provider must somehow configure itself with resources that may be needed by its I-Cards. For example, a CardSpace I-Card Provider must know the endpoint for the local Token Issuer (STS).
• Different I-Card Provider implementations use different protocols for retreiving identity information. Some might use WS-Trust to request a Digital Identity from a local STS (for self-issued cards), others from a remote STS (managed cards). Still others might retrieve identity information stored in the Identity Attribute Service
• The Higgins project is developing these types of I-Card Providers:
  • Cardspace-compatible (managed)
  • Cardspace-compatible (self-issued)
  • IdAS (variants:)
    • Username & Password - each card stores one of the user's unique un/pw combinations (pullled from browser's password manager)
    • Single Website - stores a copy of user's personal information on a website (e.g. linkedin.com, flikr, etc.)
    • Persona/Role {e.g. Shopper, Travel, Home&Personal, Health, Friends, Family} cards --for the multiple hats you wear

CardSpace-compatible I-Card Provider

• This provider will support interoperability with CardSpace relying parties and CardSpace/WS-Trust compatible IdPs.
• It will support both managed and self-issued CardSpace-compatible I-Cards
• It will be able to import CardSpace-format managed cards

Self-issued and Managed Cards

• Are single Digital Subject I-Cards
• The I-Cards implements the I-Card and TokenIssuerCard I-Card Interfaces:
• The TokenIssuerCard impl code manages the metadata necessary to request a Digital Identity token from a local or remote STS

Self-Issued Cards

• The self-issued card instances will implement the IdASCard interface (see I-Card Interfaces)
• The TokenIssuerCard impl code will leverage a local STS that can create Idemix compatible-tokens (in addition to the usual CardSpace-compatible token types)
• The IdASCard impl code manages manages the metadata necessary to retreive claims that are provided to the local STS Token Issuer

See Also

• I-Card, I-Card Interfaces
• I-Card Registry, I-Card Registry API
• Core Components