We're trying to get to a world where there is a ubiquitous, user-centric identity solution for the Internet. The result should be a safer, more trustworthy Internet.

Mike is showing a user experience for InfoCards, Microsoft's proposed identity solution. First time I've seen it. The solution, of course, is very thick client oriented since InfoCards is built into the OS. The vision is nice because there's a common experience for using InfoCards across every Web site.

A ubiquitous identity solution must accommodate mutually contradictory requirements based on context. For example, most of the time we don't want people to be able to track their identity, but in some cases (e.g. corporate audit requirements) that may be necessary.

Success, by Mike's definition, includes ubiquity, security-enhancing design and implementation, single, simple user experience across systems, simplicity in the programming model. Achieving success requires broad collaboration, encapsulation and transformation of underlying systems, technology standards, and ensuring participant benefits.

The goal of InfoCard is to be incremental to the current Web experience, rather than changing it completely. At the point where you're providing credentials, you could present the same login information you presented before or present an InfoCard claim.

Some choices Microsoft made:

• The protocol used to pass claims, etc. is separate from the payload. This allows changing payloads without changing the protocol. Design decision: do not tie solution to protocol designed around a single payload type.
• The identity selector is different and independent from the software provided by the identity provider. It's identity provider agnostic. The identity provider could be on the net, on the PC, on your phone, etc. Design decision: identity selector is a different process from the process running the identity provider.
• The identity selector is different from the metadata store. This allows metadata to be stored where ever it's convenient. Design decision: metadata store does not run in the identity selector process.
• Auditing and non-auditing identity providers are both allowed. Design decisions: support different levels of auditing requirements from relying parties and identity providers.
• Guarantee separation of contexts. Identifiers are unidirectional and the identifiers given to one relying party can't be linked to the identity given to another. Claims released to relying party is base don what they ask for.
• Facilitate data rejection. Claims in card are provided each time the relying party asks for authentication, so identity data can be thrown away by the identity provider.
• Claims do not equal trust. Higher levels of software, built on InfoCard must deliver that.
• The human token and the computational token are not the same. The use sees human friendly representation of the identity information to be released. That won't necessarily be the same format that the data is passed around. Design decision: cryptographically bind display token and computation claims to allow audit of identity provider by user or relying party auditor.
• Authentication goes both ways. Identity systems typically used to prover identity of user to relying party, but to reduce phraud, we also have to prove relying party to the user. Design decision: prove identity of sites to users before users ever interact with sites.
• Suppress complexity to allow users to have a consistent experience. This increases security. Localization of secrets is a factor.