No SAML bashing intended here

Conor Cahill (Conor's Web log of Esoterica) responds to my discussion about SAML protocol and linkability in a piece called SAML bashing – which is, by the way, absolutely NOT my intent.  I'm simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies.  I can't take up all the points he raises at this point in the flow, but encourage the reader to look at his piece… 

Conor mentions the emerging ideas for a SAML 2.0 Enabled Client/Proxy.  I want to make it clear I wasn't analysing these proposals.  I was analysing SAML as everyone knows it today – using the “http redirect” and “post” modes that have been widely deployed in portals all over the world, and don't require changes to the browser.

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion: 

• SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
• The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on – trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of “I give one of my providers permission to reach into my bank account and withdraw money to pay my bill”. I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

[Much more here…]

I think Conor is misunderstanding my intentions.  I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor's points b) and c) above would likely apply.  But we are looking at linkability precisely to judge the threats in the case where parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.)  So arguing that the identity provider will behave properly has nothing to do with what I am exploring:  risk.  I'll try to build Conor's concerns into my ongoing discussion.

In terms of Conor's point about letting his telephone company deduct directly from his bank account, that's a use case that “rings true”, but there are few companies to which I would want to give this ability.  That's my point.  We need a spectrum of technologies to handle different use cases and risk profiles.

[Update:  Conor later relents a bit in Perhaps not so much Bashing, bringing up a number of points I hope to make part of this exposition.]