The recent piece in which Hubert Le Van Gong began looking at InfoCards attracted a number of comments from the Liberty and SAML side of the house. I'm glad to see them joining with those of us already in this discussion to look at what we might accomplish together.
First up was Robin Wilton of Sun, who saw InfoCards as being, “…an interesting dimension of the whole ‘thin client/fat client’ tension”. For those who don't follow this kind of thing, a thin client is, at its most extreme, a display and keyboard with little local computing power and no state (no storage) – essentially a window onto a mainframe – er, I mean onto a powerful network-based server.
More often than not, local processing power comes in handy for some applications, so the term ‘thin client’ is used in practice to describe an approach to delivering specific applications. Generally, it refers to using a browser as a stateless window onto a server-based application. What would it mean to introduce InfoCards into such a world?
Let's remember that “InfoCards” are visual representations of identity providers (and sets of claims) that can be controlled through an “Identity Selector” crafted for choosing between “Digital Identities”.
These Digital Identities can emanate from anywhere (and from any platform) so are architecturally distinct from the client (and don't “fatten” it).
The Identity Selector itself does need to be part of the platform – in order to increase the safety and usability of the identity system by offering a consistent experience and making it very much harder for attackers to subvert than is the case with current applications and the browser-based technology.
However, there is nothing in the architecture to imply that the Identity Selector needs to store state on the thin client.
I can imagine “ultra thin” implementations of an Identity Selector store in which the card collection would be hosted by a distant web service, for example. Or better still, I can see many advantages to hosting the card collection and authentication information in some kind of dongle, or iPod, or mobile phone or wearable computer. The essential thing is that these decisions be under the control of those using the system.
So yes, we need to add identity selection as a capability required by any end point. But it would be an error to see this as requiring storage of state on the client, or as a matter of fat versus thin.
Moving on, we come to this comment on Hubert's blog by Chuck Mortimore:
At this point, Microsoft's intentions seem to be to only support the WS-* protocol stack. Requests have been made to make this pluggable, but all indications are that this will enter the market using only ws-trust and its dependent specs.
Scott Cantor, the key editor of the SAML 2.0 spec, then adds:
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.
Scott goes on to (accurately) report my view as being:
…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…
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.
Here is my thinking. I do want InfoCards to be “pluggable”. I want users to be able to plug in InfoCards that represent multiple operators, and multiple security technologies, including SAML. This is the translation of the crucial fifth law into a working system. Little is more important to me that delivering on this requirement. But the real question is one of how to best make InfoCards pluggable. Should the complexity be on the client, or should it be quarantined on specialized servers?
And now, we enter the twilight zone. As strange as some may find it, I am on the “thin client” side of the ensuing discussion. I want to achieve manageability and reduce the client security attack surface by supporting a single protocol stack between the client and security token servers. Meanwhile my friends Hubert and Scott have wandered onto the fat client side – they want to add multiple parallel protocol stacks to what will likely be the most attacked client system ever deployed.
I urge them to reconsider. We should collaborate to minimize the vulnerability of what will eventually (if we are successful) be deployed on billions of clients. If we limit the identity protocol between client and server to WS-Trust (making it at least possible to test it), it by no means limits the overall protocol options available to Scott and Hubert. The server can bridge WS-Trust to whatever other protocols it wants. The system is then eminently pluggable at a protocol level, but in managed environments, rather than in a chaos impossible to defend from attack.
Clearly, this call for minimalism on the client means the WS-Trust protocol should allow any security content to be carried by it – effective freedom of choice. It must transport any type of token. It must also allow the conversion of any set of claims into any other. It must be the meta in the metasystem.
WS-Trust is precisely such a protocol. For those who don't follow these things, it was designed as a way to build a “security token service” – a service whose very purpose is to exchange one security token for another.
I therefore hope all in this conversation will understand that I am not asking anyone to lay down their protocols! I am asking them to consider adding a token exchanger (aka Security Token Service, or STS) to their implementation, and to use the WS-Trust protocol as the way to implement this one piece of the puzzle.
We can imagine many synergistic outcomes. For example, one could have a client using InfoCard (and WS-Trust) to authenticate to the WS-Trust “head” on a portal server which is part of a Liberty federation, even though that server interacts with its partner sites using Liberty protocols. One can also imagine building a generic STS which works much like an “identity bridge”, converting SAML and Liberty identity and attribute providers into a WS-Trust InfoCard identity provider. I was thinking of these opportunities when I said, “SAML and Liberty implementations can easily interwork with this proposal – it may require some extensions to current capabilities but nothing very significant.”
One thing all of us can agree on is to be wary when an architect says, “nothing very significant”. But on this one occasion I think I can get away with it. Ping has already demonstrated that those who already have the technology necessary to do SAML or Liberty can easily add the functionality implied by WS-Trust. After all, Andre Durand was able to demonstrate such a service at the recent DIDW conference – easily interworking with InfoCards. Other providers of hardware and software are already far along in developing this capability as well.
