Wednesday May 18, 2005
- Identity selector: it will reside on the PC and will act as a sort of broker for the user by negotiating between the identity providers and the relying party. Note that the term identity provider has a quite different meaning that the one used in other identity framework (like Liberty). In Microsoft's Identity Metasystem, an identity provider issues digital identities that are relevant to the business it is in. For instance, a credit card provider would issue identities that enable payment (so credit card number info or whatever is needed for a payment). To me such identity provider is more of an attribute provider but maybe I sent too much time working on Liberty? The relying party is a service provider that is also InfoCard enabled.
- Self-issued identity provider: a PC will be able to store some of the user's personal information in a secure area of the operating system. The InfoCard client application (on the PC) can then provide these data to relying parties. Microsoft says that the data stored on the PC cannot be sensitive information (e.g. social security numbers...). While this is an interesting concept, storing locally personal attributes is raising the issue of availability: unlike digital identities stored on an identity provider the self-issued digital identities are only available when you're using your PC.
Gathering as much info as I could, I have created the following diagram to illustrate how InfoCard would actually work. I'd be happy to hear any comment on it (or corrections if I got something wrong).
Now an interesting question is how this is going to work with other identity frameworks? Microsoft called this architecture Identity Metasystem since it is supposed to be above (and play nicely with) existing systems.
I could imagine this being used on top of SAML2.0 or Liberty ID-FF1.2 but obviously this architecture is in direct competition with Liberty's ID-WSF framework.
I'm sure I'll come back to this.
Posted by Superpatterns on May 18, 2005 at 09:16 PM PDT #
Posted by Robin Wilton on May 19, 2005 at 01:32 AM PDT #
Posted by Chuck Mortimore on May 19, 2005 at 09:54 AM PDT #
Posted by 192.18.42.11 on May 19, 2005 at 10:28 AM PDT #
I can relate from conversations at DIDW that it is 100% a constraint that this InfoCard model for identity provider "discovery", as the SAML spec refers to the process, is completely tied to WS-Trust and they do not intend that it support any other authentication protocol.
WS-Trust supports SAML (and other) tokens, but the real work is done by the protocol. That's where all the current systems for federated identity compete (or converge). Tokens are largely incidental in these systems. That's why it's relatively possible for WS-* to try and be agnostic about them, but equally reasonable (IMHO) for SAML protocol to focus on SAML tokens, because they can already wrap anything else.
So, no, this does not support SAML or Liberty in the meaningful sense of "support". It's WS-* or nothing. It's up to us to decide whether we can accept those terms.
Posted by Scott Cantor on May 19, 2005 at 09:10 PM PDT #
Thank you for your explanation of InfoCard. I appreciate your insight.
Mark
Posted by Mark Dixon on May 20, 2005 at 12:12 PM PDT #
On your last paragraph: Kim seems to have an opposite point of view as, when commenting this entry on his blog, he said that "SAML and Liberty implementations can easily interwork with their proposal". Sounds more than just token support but it is still very unclear how they intend to achieve that. As you pointed out (and Chuck too) WS-* or nothing is not gonna get us there.
Cheers, Hubert
Posted by Hubert Le Van Gong on May 20, 2005 at 04:28 PM PDT #
Well Hubert, it's from Kim that I got the clear statement about what InfoCard will support, and his view was that multiple protocols introduce insecurity to the client, and are a deployment problem because of the need to keep each client up to date with each protocol. He drew the analogy of that being like "putting a router in the desktop".
He has a point, but I'll only say that WS-Trust includes (as it must) extensibility to deal with the kinds of challenge/response behavior required to use certain kinds of tokens. Once you get to that point, you've made the overall protocol exchange token-specific, just as with SASL or GSS-API mechanisms.
But in any case, you can certainly ask him what he means by "SAML and Liberty can work in this framework". But I'm pretty sure he just means that SAML assertions are supported.
Posted by Scott Cantor on May 22, 2005 at 09:40 AM PDT #