I've come across a posting by Ben Laurie which deserves comment. Ben begins this way:
Here’s some specific criticisms. Feel free to correct me if I’m wrong.
- Law 4, “Directed Identity” says
“a consumer visiting a corporate Web site is able to use the identity beacon of that site to decide whether she wants to establish a relationship with it. Her system can then set up a “unidirectional” identity relation with the site by selecting an identifier for use with that site and no other. A unidirectional identity relation with a different site would involve fabricating a completely unrelated identifier. Because of this, there is no correlation handle emitted that can be shared between sites to assemble profile activities and preferences into super-dossiers.”
However, as I’ve shown, this is not actually possible with any traditional type of signed assertion.
- Apparently, InfoCard kicks ass because its inclusive of other systems. If it were true, then it could fix the problem above by supporting Stefan Brands’ stuff (shame its patented). But, amazingly, despite the claims made, no-one actually knows whether it can!
Actually, I've been working with Stefan to ensure that Credentica (the name of Stefan's system) can work within the InfoCard model. I've said publicly that if it can't, our implementation needs to be fixed. We have figured out several possible implementations, and Stefan's team is moving forward on the analysis. Naturally we want to do a proof of concept and pilot before screaming this from the rooftops. Isn't that OK?
Further, there are additional proposals for “anonymous credentials” coming out of the academic community which also transcend the limitations of X.509 and PKI. I am workjing with other novel proposals in addition to those being made by Stefan. I have been tireless in arguing the need to support new token formats essential to such systems – rejecting the prevelant bugaboo that we should limit all future technology to SAML and then congratulate ourselves on how clever we are. Isn't that OK too?
Beyond this, the basic InfoCard implementation allows the blinding of the identity provider to the identity of the relying party by putting that identity through a one-way function with per-user salt. Any identity provider can then manufacture unidirectional identities and sign assertions without knowing what site they are being submitted to. This has none of the problems of the X.509 certificate, which really is an omnidirectional identifier. I will describe this in more detail as I go through the design decisions behind InfoCard in some upcoming postings.
Ben continues:
- A specific example given of a system that could be supported is Sxip. Yet I am told that the UI planned for InfoCard is wrong for Sxip. What use is it if the protocols support something but the user has no access to it?
To the extent that sxip wants its own unique user experience that has nothing to do with the user experience of other identity systems, then any common UI is “wrong for Sxip”. But Sxip should be able to distinguish between offering a basic identity experience within the framework of a metasystem (for example, working with InfoCard), and providing a unique value-add through its own supplementary UI (such value-add is a good and great idea).
Ben concludes:
In short, there’s a lot of hype around InfoCard – but it's increasingly unclear to me that it survives close examination. It seems to me that some of these issues could be fixed (linkability with legacy certificates does not strike me as fixable, though), but in the rush to get to market they’re being swept under the carpet.
Nothing is being swept under the carpet. My goal is to deliver increasing clarity as we move forward.
Traditional certificates are linkable. But InfoCard Identity Providers can easily produce unlinkable identity assertions. Systems like Credentica can add further advanced privacy and security properties. Systems like Sxip can expose basic capabilities through the InfoCard UI, and expose value-add in whatever ways make sense for them.
I would say the problem is not that close examination reveals defects in the InfoCard proposals, but that insufficient examination misses on the capabilities being offered and leads to false assumptions.
Is this Ben's fault? No, it's mine. I need to do a much better job of getting these capabilities documented, published and understood. I need to write in a systematic way about the design decisions and capabilities of the Identity Metasystem proposal. Hopefully as that happens we can zero in on things that need to be fixed and extended going forward.
[tags: Identity Metasystem, Ben Laurie, Design Decisions, Sxip]
