InfoCard Overview

From IdCommons

Attempt at a transcript of Kim's overview over the InfoCard implementation at IIW 2006a.

Overview diagram

InfoCard architecture overview


There are three processes:

  • user process on the desktop
  • Identity Selector user interface on a separate desktop (written in C, in order to reduce the attack surface)
  • Protocol dispatch (non-graphical, system service, managed code)

Self-asserted Identity Provider

Was not implemented as a separate process, but has the same behavior as-if.

Towards the Identity Provider

WS-Trust and Meta-Data Exchange

Towards the Relying Party

Talks either:

  • WS-Trust
  • HTTP Post -- currently only posting the token (in the future, should have a wrapper). Does the post through IE.

Towards the browser

Browser becomes an active client. When browser sees an active tag, it calls get_token interface like any other client.

API is very simple:

  • get_token
  • configure (open user interface, allows you to create / configure cards)

There is no interface for retrieving cards.

Card file

Identity provider gives user the card meta-data. Meta-data on how to contact the identity provider

Meta-data store

Wherever you wanted. (Not in V1)


Has the history of your transactions with relying party. Based on that information, the user experience can be shortened. So "introductions" have a different user experience.

Currently not importable or exportable, nor API.


The master key is modulated by the identifier of the site to create pairwise keys, so you can't assemble a dossier across sites.

If you want roaming and pairwise keys, you must have derived keys, otherwise roaming isn't practical.

PBE keys (password-based encryption).

There's a password on the master key.

Meta-data needs to be secret not because of security, but against social engineering attacks. All the data is encrypted. Can be exported, but not programmatically. Protected by two keys: must be running as a user and as the system simultaneously, so user processes nor system processes can access it.


One get_token and configure. Potentially in the future: towards meta-data exchange. Cannot see any other APIs that may become public for any reason.

File formats

Card file. Key store.

Authentication methods (added from telecon 2006-05-08)

Four different auth methods:

  • self-asserted identity provider
  • username / password (deprecated)
  • X509 certs (expectation: will typically come off a smart card or device)
  • kerberos ticket


Question: is there a point in trying to have the same APIs (Microsoft and OSIS)

Answer: there's probably a point in doing the same get_token and configure calls.

Question: what design elements / user experience should be the same?

Answer: analogy: cars. The cars differentiate, but not to the extent that it becomes unsafe (e.g. brakes in a different places). The card visuals can be the same. Ceremonies can be the same. Vista chrome decorations cannot be the same because it's the general Vista look-and-feel.

OSIS Main Page