Difference between revisions of "I-Card Provider"

Revision as of 13:07, 14 December 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

IdAS Channel I-Card Provider

<to be written> Describe this implementation of the ChannelCard I-Card interface

This page describes the base I-Card interface and the TokenCard interfaces that all types of Higgins-compatible I-Cards must implement, as well as the optional additional URICard interface.

Base ICard Interface

All I-Cards must implement the ICard Interface:

// Return the human friendly name of the card
String getDisplayName();

// Return true if this card only manages information about a
// exactly one Digital Subject
boolean isSingle();
 
// Returns if 'isSingle()' is true, an optional contextually-unique 
// identifier for the Digital Subject
// Otherwise return null.
String getCUID();

// A card identifier that is unique to the card issuer. Or at least that
// is what we believe the semantics that Microsoft intended and we currently
// see no reason not to follow
// Return the identifier string   
String getCardID();

// Returns the human friendly name of the card issuer
String getIssuerName();

// Returns the URI of the issuer
String getIssuer();

// Returns a background image of the card
Image getCardImage();

// Return the mime type of the background image (JPEG or GIF)
String getImageMimeType();

// Returns when the card was first issued, created, orginated
Date getTimeIssued();

// Returns (optionally) the time after which the card should
// be considered expired, invalid. Otherwise returns null
Date getExpiredTime();

// If card handles only simple claim types then 
// return a list of all possible types of claims that are supported
// throw exception otherwise
// This is here for backward compatibility with CardSpace cards
//
// Note: this is a convenience method that does the equivalent of
// c = getContext(); and then (presuming c has a simple schema)
// does creates a linear list of claim/attribute types from 
// the schema of c (retrieved by c.getSchema()) 
List getSupportedSimpleClaimTypes() throws ComplexSchemaException;

// Returns a read-only Context whose Digital Subject(s) can be queried for 
// attribute values that are displayed in the card UI (e.g. the
// I-Card Selector Service or I-Card Manager. 
// See also isSingle() retreive the CUID of the singleton Digital Subject
// If a card does not support a display context it throws the 
// NoDisplayContextException. In this case the user cannot see
// the values of the supported claim types, only the claim types 
// themselves.
Context getDisplayContext() throws NoDisplayContextException;

// Retrieve the value of a simple claim type (on a 'single' card)
// Note 1: Implementations of this method will likely retrieve and cache all 
// supported simple claim type values in a single operation 
// Note 2: This is a convenience method that performs a getContext()
// to get the context, finds the singleton DS, and reads the claimType
// attribute specified
// Returns the value of the claim type ClaimType
String getClaimValue(String claimType) throws ComplexSchemaException;

// Return whether the user wishes to be asked for explicit release of
// this card's information (i) every time it is requested (ii) only 
// the first time it is requested (iii) never 
ReleasePolicy getReleasePolicy();

// Set the release policy of this card
void setReleasePolicy(ReleasePolicy) throws CardNotOpenException;

// Return a list of the types of expored card data stream formats supported
// ?? presumably a CardFormat also mentions XML language and/or version number
List getSupportedExportFormats();

// Return a data stream containing a serialization of the card
// The format depends on the kind of card 
// E.g. CardSpace I-Cards will export CardSpace format data
String export(CardFormat format);

// UPDATE-RELATED METHODS

// Open the card itself for update. These methods are
// used during the creation of a new self-issued card.
// Pass the URI of the agent that intends to update the card. 
// If the editorID matches the issuerID of the card then 
// update operations are allowed
// Throws CardNotOpenException if 'editorID' does not match the 
// value of getIssuerURI()
final void open(String editorID);

// Return true if card is open for update
boolean isOpen();

// Close a card for update.
void close() throws CardNotOpenException;

// Set the human friendly name of the card
// throws: CardUpdateException if card has not been opened
void setDisplayName(String name) throws CardNotOpenException;

// Sets the card's human friendly name of the card issuer
void setIssuerName(String name) throws CardNotOpenException;
 
// Sets the background image of the card
void setCardImage(Image image) throws CardNotOpenException;

// Set the expiration date and time
void setExpiredTime(Date date) throws CardNotOpenException;

To Do

• Future: we may want to add methods to the a human friendly text name and an icon that informs the user about the kind of data access "protocol" used (if any) to retrieve the underlying data. Examples of strings might be "LDIF", "OpenID", "WS-Trust", etc.
• Future: we may want to add methods (analogous to the ones mentioned above) to inform the user about the format of the underlying data (e.g. LDAP, RDF, RDBMS, email contacts, etc.)

TokenCard Interface

All I-Cards must implement this interface.

// If card is of type (1) then return a Digital Identity 
// that satisfies the policy policy
// The credential parameter used to authenticate to the 
// Token Issuer–-may be null if Token Issuer policy doesn’t require it
DigitalIdentity requestDigitalIdentity(Policy policy, DigitalIdentity credential);

// Return the EPR of the card issuer
// For CardSpace cards this is either the local STS endpoint (for
// self-asserted cards) or a remote STS (for managed cards)
EndpointReference getCardIssuerEndpoint();

// Return a list of {endpoint references, credential hint, credential selector}
List getTokenServices()

// Return a list of supported token types
List getSupportedTokenTypes(); 

// Is the RP identity required in the token request message?
boolean getRequireAppliesTo()

// Returns the issuer that is referenced in the returned RSTR 
// (or null if no issuer is listed)
String getIssuedTokenIssuer();

URICard Interface

Some types of I-Cards may implement this interface. The card object includes a ContextRef URI (which may be an XRI) that refers to an identity attribute-providing service (usually a network endpoint).

The I-Card Providers developed as part of the Higgins project use the Identity Attribute Service to connect to the remote (or local) Context data referenced by this ContextRef

Note: If ICard.isSingle() is true, then implementations can invoke ICard.getCUID() to retreive the CUID of the Digital Subject with the Context returned by .getContextRef() below.

// Return the ContextRef of the card
String getContextRef();

See Also

• Higgins Home
• I-Card, I-Card Interfaces
• I-Card Provider
• I-Card Registry, I-Card Registry API
• Architecture
• Components
• Deployments