InfoCard Overview
Attempt at a transcript of Kim's overview over the InfoCard implementation at IIW 2006a.
Contents
Overview diagram
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.
