Paul and Gerry have been talking about levels of assurance for self-asserted vs. managed cards, loosely based on my Let’s talk Turkey entry from awhile back. Paul calls Gerry’s stance hard-line; I’m inclined to agree.

Gerry states:

… as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

1. No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
2. Assurance – managed cards where a particular set of Issuer(s) is required by the R[P]

Gerry also states that it’s ok to have no assurance for “low-value transactions”. This seems like a very strange statement to me. Whether you are a blog or a bank, you still want to have confidence that the the card and the data in it is correctly associated with the right account. Perhaps the bank cares more about the veracity of additional claims — but in my mind, any additional level of confidence in quality of data must first be based on a foundation of accurate identification.

Such thoughts led me to ask & try to answer the following question: Should an RP feel more confident in receiving a managed card from a user compared to a self-issued card?

For the purposes of token validation, the only thing I as an RP get in a managed card that I don’t get in a self-issued card (that I can think of anyway) is a certificate that is chained to a “trusted root certification authority”. This, of course, only gives me more actual assurance if I go to the trouble of verifying that the cert does indeed chain properly, and that it hasn’t been revoked.

As far as data veracity goes — well that has nothing whatsoever to do with the card format. It just as equally easy and possible to lie through a managed card as it is to lie through a self-issued card. The format guarantees nothing. Trusting a managed card because it is a managed card over a self-issued card is the equivalent of trusting hearsay over perjury.

A card issuer that simply parrots back what a user types into it will have certain uses, regardless of the issuing mechanism. A card issuer that adds value to what the user supplies will gain over time a different kind of reputation, and therefore will inspire a different level of confidence in both users and relying parties. Mistakes, abuse, quality of user experience, extra features – all of these things will play into trust decisions for transactions of all kinds, and of all values.  Dividing things into low-value vs. high-value classifications seem like a good way to divide things – but not with respect to identification mechanism. Think of the gmail user who becomes a Google payment user. A relying party in a high-value payment transaction involving a Google user still has to depend on the same identification mechanism used for a low-value google mail transaction. The foundations are the same – it has to work and it has to have some kind of assurance attached, for relying parties and users too.