Information card


An information card is a personal digital identity that people can use online, and the key component of an identity metasystem. Visually, each i-card has a card-shaped picture and a card name associated with it that enable people to organize their digital identities and to easily select one they want to use for any given interaction. The information card metaphor has been implemented by identity selectors like Windows CardSpace, DigitalMe or Higgins Identity Selector.
An identity metasystem is an interoperable architecture for digital identity that enables people to have and employ a collection of digital identities based on multiple underlying technologies, implementations, and providers. Using this approach, customers can continue to use their existing identity infrastructure investments, choose the identity technology that works best for them, and more easily migrate from old technologies to new technologies without sacrificing interoperability with others. The identity metasystem is based upon the principles in "The Laws of Identity".

Overview

There are three participants in digital identity interactions using information cards:
  • Identity providers issue digital identities for you. For example, businesses might issue identities to their customers, governments might vouch for the identities of their citizens, credit card issuers might provide identities enabling payment, online services could provide verified data such as age, and individuals might use self-issued identities to log onto websites.
  • Relying parties accept identities for you. Online services that you use can accept digital identities that you choose and use the information provided by them on your behalf, with your consent.
  • Subject is yourself, the party in control of all these interactions. The subject can choose which of its applicable digital identities to use with the relying party.

    Selectors

An identity selector is used to store, manage, and use their digital identities. Examples of identity selectors are Microsoft's Windows CardSpace, the Bandit Project's DigitalMe, and several kinds of Identity Selectors from the Eclipse Foundation's Higgins project.
An identity selector performs the following user-centric identity management tasks:
  • Provides a consistent user experience for authentication with an RP.
  • Provides a user interface that displays a set of information card icons from which the user selects their preferred i-card when authentication is required by a local application or relying party.
  • Provides a user interface to create and manage personal information cards.
  • Provides a local security token service that is used to issue the security tokens for personal i-cards.
  • Provides a user interface to import and export information cards in standard file formats.
  • Is invoked by a browser extension or by a local rich client application.
An identity selector may also allow the user to manage their portfolio of i-cards.

Identity metasystems

There are five key components to an identity metasystem:
  • A way to represent identities using claims. Claims are carried in security tokens, as per WS-Security.
  • A means for identity providers, relying parties, and subjects to negotiate. Dynamically negotiating the claims to be delivered and the security token format used enables the identity metasystem to carry any format of token and any kinds of claims needed for a digital identity interaction. Negotiation occurs using WS-SecurityPolicy statements exchanged using WS-MetadataExchange.
  • An encapsulating protocol to obtain claims and requirements. The WS-Trust and WS-Federation protocols are used to carry requests for security tokens and responses containing those tokens.
  • A means to bridge technology and organizational boundaries using claims transformation. Security token services as defined in WS-Trust are used to transform claim contents and formats.
  • A consistent user experience across multiple contexts, technologies, and operators. This is achieved via identity selector client software such as Windows CardSpace representing digital identities owned by users as visual i-cards.

    Generic qualities

  • I-cards are created by an entity known as a issuer.
  • I-cards display the name of the issuer in a text string.
  • I-cards have a text string to identify the card that is initially set by the card issuer. Typically this card name is user-editable.
  • I-cards may have a background image set by the card issuer.
  • In most i-cards the user is able to see the value of the claims.

    Sign-in capabilities

Using i-cards, users can authenticate without needing a username and password for every website; instead, at sites accepting them, they can log in with an i-card, which may be used at multiple sites.
Each information card utilizes a distinct pair-wise digital key for every realm where a key is requested. A realm may be a single site or a set of related sites all sharing the same target scope information when requesting an information card. The use of distinct pair-wise keys per realm means that even if a person is tricked into logging into an imposter site with an i-card, a different key would be used at that site than the site that the imposter was trying to impersonate; no shared secret is released.
Furthermore, many identity selectors provide a means of phishing detection, where the HTTPS certificate of the relying party site is checked and compared against a list of the sites at which the user has previously used an information card. When a new site is visited, the user is informed that they have not previously used a card there.

Types of i-cards

The Identity Selector Interoperability Profile v 1.5 specifies two types of information cards that an identity selector must support.
  • Personal Information Cards: these cards allow you to issue claims about yourself to sites willing to accept them. These claims can include your name, address, phone numbers, e-mail address, web address, birth date, gender, and a site-specific key uniquely generated for each site where the card is used.
  • Managed Information Cards: These cards allow identity providers other than yourself to make claims about you to sites willing to accept them. These claims can include any information that an RP requests, an identity provider is able to provide, and you are willing to send between them.
The Higgins project is defining two new kinds of i-cards as well:
  • Relationship cards are used to establish an ongoing relationship between multiple parties.
  • Zero-knowledge cards
However the Information Card format allows for custom types; The Bandit project demonstrated prototype managed cards backed by OpenIDs at the Novell BrainShare conference in March 2007.

Personal cards

The first kind of personal Information cards were also introduced as part of Microsoft’s Windows CardSpace software in November 2006. Their behavior is also defined by the same documents covering the Microsoft-defined managed cards.
Summary of characteristics:
  • Data format an XML file containing: set of claim type URIs as well as the values of these claims, cardImage, a unique cardID, etc. This data format is defined in the ISIP documents.
  • Issuer: The user's own Identity Selector. Personal cards can be described as self-issued
  • Genesis: Created by the user's Identity Selector.
  • Claims: 15 pre-defined claim types are defined in the Identity Selector Interoperability Profile v 1.5.
  • Authority: The user's Identity Selector is the authority for the issued token's set of claim values.
  • Data flow: On demand, an STS local to the Identity Selector creates a security token with the current values.
  • Editability: The claim values are directly editable by the user.
  • Attribute data source: The personal card XML file contains claim values. When imported into an Identity Selector these data values are then managed internally by the selector.

    Managed information cards

The first kind of managed card was introduced as part of Microsoft’s Windows CardSpace software in November 2006. The behavior, file format and interoperability characteristics of these kinds of managed cards are defined by Microsoft documents such as the Identity Selector Interoperability Profile v 1.5, in combination with open standards including WS-Trust and others.
Summary of characteristics:
  • Data format: an XML file containing: network endpoint of the STS, set of claim type URIs, name of the card, cardImage, issuerName, a unique cardID, etc. The XML file format is defined in the ISIP documents.
  • Issuer: An external, third party token service.
  • Genesis: A managed card is generated by a Security Token Service running at an Identity Provider site and imported into the user's Identity Selector.
  • Claims: The list of supported claim types is defined by the issuer.
  • Authority: The issuer is the sole authority for the claim values contained within the token it issues.
  • Data flow: Managed cards contain a network endpoint reference to an STS that, when requested by the Identity Selector generates/provides a security token containing the required claims.
  • Editability: Underlying attribute data is not directly editable by the user.
  • Attribute data source: Determined by the issuer, and generally managed by the issuer.
I-cards issued by third parties can employ any of four methods for the user to authenticate himself as the card owner:
  • a Personal Information Card,
  • an X.509 certificate,
  • a Kerberos ticket, such as those issued by many enterprise login solutions, or
  • a username and password for the card.
Additional methods could also be implemented by future identity selectors and identity providers.
Managed i-cards can be auditing, non-auditing, or auditing-optional:
  • Auditing cards require the identity of the RP site to be disclosed to the Identity Provider. This can be used to restrict which sites the identity provider is willing to release information to.
  • Non-auditing cards will not disclose the identity of the RP site to the Identity Provider.
  • Auditing-optional cards will disclose the identity of the Relying Party site if provided by the RP, but do not require this disclosure.