I hate to be a stickler here — but I still hate all of these generalizations. Sorry Gerry, Paul — I’m not trying to be mean, but my Implementer spidey-sense won’t stop tingling here. I hope I can explain some of my concerns here – and then I think I’ll have to put my money where my mouth is and write something in response that has a bit more meat to it.

If my bank were to one day allow me to associate an information card with my account, I see absolutely no reason why I would hesitate to associate a self-issued information card. If I’m reading Gerry’s taxonomy correctly, in doing so I would be doing my daily banking via a pseudonym-based, no assurance, low-value transaction. If I read Paul’s taxonomy correctly, there would be technical confidence but no legal confidence, even though I as an end user do indeed have a contract with my bank.

Let’s go past an authentication-only scheme and say that my bank will trust everything I assert from my self-issued card. That boils down to contact information — the same stuff that many websites let me change already. I can use a web form, the telephone, probably even a fax machine to do this already, and if I were to change my name on my bank account to “Mindy the Marvelous Mouse”, using any of those methods (including any kind of card), the consequences (legal or not) of doing so would be identical regardless of the actual mechanism I used to make my claims. So – in my mind, legal confidence with respect to fraud on the part of the claim originator should have nothing to do with the delivery mechanism. On the other hand, legal confidence with respect to impersonation of the claim originator may have a very different look and feel. Depending where the blame lies for the impersonation, the RP may not even be able to sue the claim originator, because they may not be at fault or even involved (or their terms of use may disclaim all liability, not sure if that really sticks legally or not). All of this points to the fact that you definitely do want to consider the delivery mechanism when deciding what mechanisms you allow in the first place — but if the system compromise happens at a low enough level, it no longer matters who you trust to say what (theoretically the big difference between self-issued and managed cards), because you can’t even guarantee the who, let alone the what. I don’t see an obvious reason why it would be easier to compromise an Identity Selector than an IdP — either way, there is certainly no reason to malign either card mechanism until proof exists that either one is more vulnerable than the other.

But wait, you say, how about data with real legal teeth? What if my bank allowed me to use my self-issued card to make claims about my own credit score?

Self-issued cards can’t make claims about credit score or SSN number or bank account number. They are incapable – by design. For what they can do, I believe they can do it well. For the rest, they are simply not applicable – which to me is very different from being low in assurance.

In summary, the only situation I can see where use of a self-issued card means a possible legal or technical setback of any kind for an RP (within the normal uses of such a card), is in a case where normal contact data is changed by the user to be fraudulent. I don’t think this case is much of a big deal — because people can do that now, via other channels, and it is a known risk that websites already seem to accept. If there are other cases which I’m missing, please let me know.

I apologize for continually throwing rocks at other people’s glass houses – I realize it’s a lot easier to criticize than to create. As soon as I have a free moment, I’ll try to write out all of what I consider to be valid factors, so that everyone can have a chance to throw rocks at my glass house too :)