[jarrett]

I understood this to be something different from what Schneier describes. (Though I could be mistaken.) I took this to be primarily an API for Internet applications to verify an end user's identity claims. I realize there are physical cards involved, and those could be problematic, but the API part sounds better.

The failure modes Scheier describes would still be applicable, of course. But as a developer, I might still appreciate having the system available. I couldn't trust its responses beyond a reasonable doubt. But still it might be valuable to have some extra degree of certainty about a user's identity, in some scenarios.

Let's say, for example, I'm developing an online liquor store. Let's say I accept various forms of payment, some of which don't come with age verification. I might appreciate a simple, unified ID API for that purpose. Granted, it would still be possible for minors to exploit the vulnerabilities Schneier describes and buy alcohol from me. But conceivably, if that happened, the law might grant me immunity, because I checked against the government API and the failure was on the government's part. Which would be a valuable assurance for me as the developer or business owner.

[kiiski]

In Finland we have a system based on authenticating through your bank (TUPAS[1]). It works pretty well, and is easy, at least for the end-user, to use (you just select your bank and get redirected to their login site; the banks system then passes your info to the site). I don't know what kind of requirements there are for businesses to use it though.

[1] http://en.m.wikipedia.org/wiki/TUPAS