Paul and Pam seem to think that my stance on assurances and trust is hard-line.
No Assurance vs. Pseudonymity
Paul seems to agree with me to some extend while noting that a concept like self-issued cards can establish a stable pseudonym. I agree with this: both the Windows CardSpace system, as well as OpenID produce in their basic usage scenarios[1] stable pseudonyms – not more, not less. But this conveys nothing about the identity of the user controlling this pseudonym. It is purely an authentication process that takes place, with no authorization data being exchanged. In fact, all authorization takes place within the RP system, solely based on the pseudonym. I called that the “No assurance” level, which is – a little – harsh, but still fair.
Pseudonymity and Low-Value Transactions
Pam has more issues with my analysis: initially, she finds it strange that “No assurance”, pseudonym-only level of assurance is acceptable at all. Again, I might have been somewhat extreme in my wording: when speaking about “No assurance” I was speaking about a situation, where some authentication, but no authorization took place. So you do have (as Paul pointed out) a stable pseudonym, but absolutely no reliable information beyond that. This, I find completely acceptable to what I coined “low-value transactions” like forums, blog commenting, etc.
Trusting an IdP
Now Pam goes on to point out, that an arbitrary managed card provider has – beyond the certificate that confirms the identity of the IdP to only some extend – no other trustworthiness to them, making them practically as unreliable as a self-issued card.
I agree totally. That is why I insisted in my earlier article that in order to gain any confidence in the token, the RP has really no other choice but to set the sp:IssuedToken/sp:Issuer (3.1.1 [ISIP 07]) to a WSA Endpoint that the RP is willing to trust. This trust is established through non-technical means, e.g through contracts, reputation systems, etc. But without this tying of the authentication to an IdP you have at least some trust in, you cannot have any reasonable level of assurance about your attributes.
The Energy Level Diagram of Assurance
Thus, I also agree with Kim: assurance is not binary – quite the opposite. For reasons of brevity (and laziness 8-)) I only focused on the two major categories of assurance for authenticated session. So here is now a somewhat more complete picture:
Please note that in this picture “No assurance” refers to completely anonymous transactions (no authentication), while the former level of that name is now name “Pseudonymity”.
At the end of the day, however, I come back to the same point I made in my earlier post: technology (as long as it is not blatantly broken, i.e. insecure) bears no significant role in establishing trust or assurance. You cannot create a technology that has “built-in” trust – any technology can be deployed in a completely untrustworthy way.
Even a technology-centric system like SSL rests on the trustworthiness of the browser programmers (that put roots in the CA stores) and the CA companies themselves.
tag: identity, assurance, cardspace
[1] Windows CardSpace: self-asserted cards, OpenID: OpenID Auth 1.1 + SimpleReg 1.0
[ISIP 07] Arun Nanda, “Identity Selector Interoperability Profile V1.0”, Microsoft, April 2007