The Emergent Chaos Jazz Combo

Main menu

Post navigation

Infocard, Demystified

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.’

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.

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.

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.

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.
[Update: Kim has a response, “ADAM ON DEMYSTIFYING INFOCARDS,” that I won’t be able to respond to until tonight or perhaps tomorrow. Since trackbacks are off (spam), I figured I’d link.]

3 thoughts on “Infocard, Demystified”

I’d like to correct your comment that “the certifying authority can track every site you visit”. The InfoCard system supports what we call “non-auditing” identity providers. Please check out this page of the tutorial accompanying the video. I say:

Before going further, I’d like to point out that 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.

Both types of provider have their place. For the purposes of this example, we’ll assume the Identity Provider is of the auditing type and has done the encryption for the relying party. Note that the relying party doesn’t actually see any difference.

This provides a lack of visibility. Stephan’s work – which I would like to see incorporated into the InfoCard framework – adds a proof-key to the bearer semantics used for non-auditing providers. This strengthens the proof of ownership of the token, but doesn’t affect the privacy.

Maybe I am just obtuse, but I think InfoCard is an incredibly dumb name — although though the idea it embodies is a good one.
It seems to me that Kim’s metasystem is all about *identity*. Why is it not called IdentityCard? Would that be too obvious? Not sufficiently copyrightable? Too likely to give the Bill Safire the hives?