InfoCard Overview

From IdCommons

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

Overview diagram

InfoCard architecture overview

Processes

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)

Ledger

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.

Keys

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.

APIs

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

Q&A

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