A Guide to Integrating with InfoCard

I have to apologize for dropping out off the face of the earth for a while.

I've been in input mode – meeting with a whole series of absolutely brilliant people from all over the world – and just as many walks of life. I wish I could share the contents of those discussions, but unfortunately all I can do is try to infuse my work with what I've learned.

Meanwhile, some news that really means a lot to me. We have completed all the hoops necessary to publish a really detailed technical explanation of InfoCards that allows anyone and everyone to interoperate with Microsoft products through open web services protocols.

There are two documents. To me, the most important is “A Guide to Integrating with InfoCard v1.0“. I want to thank the people at Ping Identity Corporation - significantly innovative engineers who have already demonstrated interoperability with InfoCards – for helping to put this publication together. I think the result is clear and will make sense to people coming at interoperability from a non-microsoft point of view.

Here's the abstract:

The InfoCard system in the Windows Communications Foundation (WCF) of WinFX allows users to manage their digital identities from various identity providers, and employ them in different contexts where they are accepted to access online services. This Guide describes a model built upon the mechanisms described in [WS-Trust] and [WS-SecurityPolicy] to allow digital identity to be integrated into a user-centric identity framework that promotes interoperability between identity providers and relying parties with the user in control.

The mechanisms described in this document provide the framework for an identity metasystem. The interactions between the InfoCard system and a relying party or an identity provider are illustrated to allow others to create identity systems and applications that can use and interoperate with the Windows InfoCard system in WCF. This document is intended to be read alongside the InfoCard Technical Reference [InfoCard-Ref] which provides the normative schema definitions and behaviors referenced by this document.

What is the status of these documents? We see the relevant standards as being WS-Trust, WS-SecurityPolicy, and WS-Security. The Guide is really a document intended to make it as easy as possible to achieve interoperability with the InfoCard system that will be present in Windows Vista and XP. Our goal has been that no one will have to “reverse engineer” anything to play – it's all described. The authors put it this way:

This draft of the InfoCard Guide reflects what is implemented by the InfoCard system in WCF in the Beta2 release of WinFX. The documented behavior and schema described here are subject to change in the final release of the product.

I want to introduce readers to Arun Nanda, the product architect for InfoCard, and the man responsible for these documents from the Microsoft end. Arun is wonderfully open and innovative by nature. I've had a ball working with him. And no one could have done a better job at conceptualizing and rationalizing the vast array of protocol decisions, nuances and details involved in building a flesh and blood metasystem.

Making InfoCard design decisions clear

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: , , , ]