ADAM ON DEMYSTIFYING INFOCARDS

Adam at Emergent Chaos has taken a stab at demystifying InfoCards:

For every product, there are thousands of sentences which result in the reply “well, why didn't you just say that?” The answer, of course, is that there are thousands, and often its not clear which is the right one. For me, the useful sentence is that ‘Infocard is software that packages up identity assertions, gets them signed by a identity authority and sends them off to a relying party in an XML format. The identity authority can be itself, and the XML is SAML, or an extension thereof, and the XML is signed and encrypted.’

Hmmm.  Thanks Adam.  No cigar, but we're getting closer.

Actually, the relying party states what assertions it wants, the Identity Selector allows the user to control what identity provider to use, and the identity provider packages up the identity assertions, signs them and sends them to the relying party in a token format.  The identity authority can be something local to the identity selector, or something reachable over the internet, and the token format can be XML, including SAML, or anything else.  The whole visual metaphor and user experience is called InfoCard, the protocols are WS-Trust, and the mesh of interoperating parties and technologies are the Identity Metasystem.

It feels like together we have put together a pretty good definition.  Comments?

Why didn't you just say that? (Actually, Kim Cameron says just about that in the video linked to in “The Infocards For PHP Tutorial.”)

True.  Why didn't I just say that?

More seriously, I'm unsure if Infocard is the software, the protocol, or some combination thereof. But I do have a much better understanding of how it works, so I'm glad to have watched the short movie demo.

Yes, I've been sloppy about all of this, and the fact that InfoCard is just a code name doesn't help either.  Anyway, InfoCard is really the visualization and experience that represents an identity within an identity selector. 

A couple of thoughts:

• First, Stephan Brands of Credentica has comprehensively analyzed the privacy issues in this sort of scheme in his book, “Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy.” The essential point to be aware of is that the certifying authority can track every site you visit. Infocard includes a self-signing authority, so you're aware of every site you visit. If web sites start demanding certificates from other organizations, they have a deep view into your web activities.

See my comments below…

• The demo code relies on Javascript. Is there anything other than the “onClick” that requires it? Javascript dramatically expands the browser's attack surface, helps phishers confuse users, etc. It would be good for Infocard to work without relying on it.

I need to think more about this.

• Finally, there's a card which is greyed out, which Kim helpfully explains is greyed out because it doesn't include an email address. I'm expecting there's an easy way for the user to discover this?

Anyway, I'm glad that Kim produced the video, and if you've been like me, watching and not having time to dig in, go watch it.

I'm happy the video is helping clarify things.  InfoCards are really easy to use, but hard to explain to a technical audience.

No tracking 

I have to correct Adam's assertion that “the certifying authority can track every site you visit”.

The InfoCard system supports what we call “non-auditing” identity providers. As I say in the tutorial accompanying the video:

The InfoCard system supports two classes of Identity Provider.

“auditing” identity providers know what Relying Party the subject is visiting. They therefore encrypt directly to the relying party.

“non-auditing” identity providers, are not, for privacy reasons, told the identity of the relying party. Therefore, they can't encrypt for it. Instead, they send the token to the InfoCard client, which in turn encrypts it for the Relying Party.

Non-auding identity providers don't have visibility into the sites you visit.

Stephan's work – which I would like to see incorporated into the InfoCard framework – adds a proof-key to the bearer semantics currently used for non-auditing providers. This strengthens the proof of ownership of the token and is a good thing, but it doesn't affect the privacy of the system.