Difference between revisions of "I-Card Provider"

Revision as of 02:25, 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

RSS-P I-Card Provider

• This provider "projects" a Digital Identity to an external site as an RSS+SSE feed. The relying site may optionally also be able to provide a feed in the reverse direction to allow the relying site to update the identity information
• RSS-P I-Card Providers implment the I-Card, URLIssuerCard, and IdASCard interfaces

SSFF Provider

• Implements the I-Card, IdASCard, and SSFFCard I-Card Interfaces
• The IdASCard implementation code uses IdAS to manage the identity data that is being synchronized (via HTML scraping and form filling)
• The SSFFCard implementation code returns to HBX the script necessary to perform screen scraping and form filling on the target site

See Also

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