In Context

Problem statement

We have no name for the “protocol that defines the interaction between a card selector and a relying party Website (or a local relying party application) that was originally defined by Microsoft in the “Identity Selector Interoperability Profile” (ISIP) documents, is now being standardized at the OASIS IMI TC and was first implemented by CardSpace™ (and later independently by others).”

[BTW, we also lack a name for the set of protocols (centered on WS-Trust, but including WS-MetadataExchange, and others) that define the interaction between a card selector and an STS (IdP), but I think calling this WS-Trust or WS-* will probably suffice for most cases. Since only IdPs care about this protocol suite, and since there are so many fewer of these than RPs this naming problem is a less pressing issue.]

Three candidates found in the wild

• Some folks call the <no-name> protocol “Information Card” (or InfoCard or I-Card). For example, major websites are telling us that they would like to support both the “OpenID” protocol and the “Information Card” protocol. The problem is, this usage confuses a user metaphor with a protocol. Information Cards (and selectors) will ultimately work with lots of protocols (e.g. <no-name>, OpenID, and SAML) as well as a with a perenial favorite of mine “username/password!”

• Some folks refer to the <no-name> protocol as “IMI” after the name of the OASIS Technical Committee mentioned in the problem statement above.

• Many folks (especially in Europe) refer to the <no-name> protocol as “CardSpace.”

My two cents…

In formal documents (e.g. at the ICF) we could refer to it as “IMI Protocol” and informally we could call it the IMI(CardSpace) Protocol.

Apologies all around

If this is the direction we as a community take, then I want to apologize to Stefan at Fun Communications and lots of other folks for my earlier confusion on this matter.