Doing it right: Touch2Id

And now for something refreshingly different:  an innovative company that is doing identity right. 

I&#39m talking about a British outfit called Touch2Id.  Their concept is really simple.  They offer young people a smart card that can be used to prove they are old enough to drink alcohol.  The technology is now well beyond the “proof of concept” phase – in fact its use in Wiltshire, England is being expanded based on its initial success.

  • To register, people present their ID documents and, once verified, a template of their fingerprint is stored on a Touch2Id card that is immediately given to them. 
  • When they go to a bar, they wave their card over a machine similar to a credit card reader, and press their finger on the machine.  If their finger matches the template on their card, the lights come on and they can walk on in.

   What&#39s great here is:

  • Merchants don&#39t have to worry about making mistakes.  The age vetting process is stringent and fake IDs are weeded out by experts.
  • Young people don&#39t have to worry about being discriminated against (or being embarassed) just because they “look young”
  • No identifying information is released to the merchant.  No name, age or photo appears on (or is stored on) the card.
  • The movements of the young person are not tracked.
  • There is no central database assembled that contains the fingerprints of innocent people
  • The fingerprint template remains the property of the person with the fingerprint – there is no privacy issue or security honeypot.
  • Kids cannot lend their card to a friend – the friend&#39s finger would not match the fingerprint template.
  • If the card is lost or stolen, it won&#39t work any more
  • The templates on the card are digitally signed and can&#39t be tampered with

I met the man behind the Touch2Id, Giles Sergant, at the recent EEMA meeting in London.

Being a skeptic versed in the (mis) use of biometrics in identity – especially the fingerprinting of our kids – I was initially more than skeptical. 

But Giles has done his homework (even auditing the course given by privacy experts Gus Hosein and Simon Davies at the London School of Economics).  The better I understood the approach he has taken, the more impressed I was.

Eventually I even agreed to enroll so as to get a feeling for what the experience was like.  The verdict:  amazing.  Its a lovely piece of minimalistic engineering, with no unnecessary moving parts or ugly underbelly.    If I look strangely euphoric in the photo that was taken it is because I was thoroughly surprised by seeing something so good.

Since then, Giles has already added an alternate form factor – an NFC sticker people can put on their mobile phone so they don&#39t actually need to carry around an additional artifact.  It will be fascinating to watch how young people respond to this initiative, which Giles is trying to grow from the bottom up.  More info on the Facebook page.

Bizzare customer journey at myPay…

Internet security is a sitting duck that could easily succumb to a number of bleak possible futures.

One prediction we can make with certainty is that as the overall safety of the net continues to erode, individual web sites will flail around looking for ways to protect themselves. They will come across novel ideas that seem to make sense from the vantage point of a single web site. Yet if they implement these ideas, most of them will backfire. Internet users have to navigate many different sites on an irregular basis. For them, the experience of disparate mechanisms and paradigms on every different site will be even more confusing and troubling than the current degenerating landscape. The Seventh Law of Identity is animated by these very concerns.

I know from earlier exchanges that Michael Ramirez understands these issues – as well as their architectural implications. So I can just imagine how he felt when he first encountered a new system that seems to represent an unfortunately great example of this dynamic. His first post on the matter started this way:

“Logging into the DFAS myPay site is frustrating. This is the gateway where DoD employees can view and change their financial data and records.

“In an attempt secure the interface (namely to prevent key loggers), they have implemented a javascript-based keyboard where the user must enter their PIN using their mouse (or using the keyboard pressing tab LOTS of times).

“A randomization function is used to change the position of the buttons, presumably to prevent a simple click-tracking virus from simply replaying the click sequence. Numbers always appear on the upper row and the letters will appear in a random position on the same row where they exist on the keyboard (e.g. QWERTY letters will always appear on the top row, just in a random order).

“At first glance, I assumed that there would be some server-side state that identified the position of the buttons (as to not allow the user&#39s browser to arbitrarily choose the positions). Looking at how the button layout is generated, however, makes it clear that the position is indeed generated by the client-side alone. Javascript functions are called to randomize the locations, and the locations of these buttons are included as part of the POST parameters upon authentication.

“A visOrder variable is included with a simple substitution cipher to identify button locations: 0 is represented by position 0, 1 by position 1, etc. Thus:

VisOrder =3601827594
Substitution =0123456789
Example PIN =325476
Encoded =102867

“Thus any virus/program can easily mount an online guessing attack (since it defines the substitution pattern), and can quickly decipher the PIN if it has access to the POST parameters.

“The web site&#39s security implementation is painfully trivial, so we can conclude that the Javascript keyboard is only to prevent keyloggers. But it has a number of side effects, especially with respect to the security of the password. Given the tedious nature of PIN entry, users choose extremely simplistic passwords. MyPay actually encourages this as it does not enforce complexity requirements and limits the length of the password between 4 and 8 characters. There is no support for upper/lower case or special characters. 36 possible values over an 4-character search space is not terribly secure.”

A few days later, Michael was back with an even stranger report. In fact this particular “user journey” verges on the bizarre. Michael writes:

“MyPay recently overhauled their interface and made it more “secure.” I have my doubts, but they certainly have changed how they interact with the user.

“I was a bit speechless. Pleading with users is new, but maybe it&#39ll work for them. Apparently it&#39ll be the only thing working for them:

Although most users have established their new login credentials with no trouble, some users are calling the Central Customer Support Unit for assistance. As a result, customer support is experiencing high call volume, and many customers are waiting on hold longer than usual.

We apologize for any inconvenience this may cause. We are doing everything possible to remedy this situation.

Michael concludes by making it clear he thinks “more than a few” users may have had trouble. He says, “Maybe, just maybe, it&#39s because of your continued use of the ridiculous virtual keyboard. Yes, you&#39ve increased the password complexity requirements (which actually increased security), but slaughtered what little usability you had. I promise you that getting rid of it will ‘remedy this situation.'”

One might just shrug one&#39s shoulders and wait for this to pass. But I can&#39t do that.  I feel compelled to redouble our efforts to produce and adopt a common standards-based approach to authentication that will work securely and in a consistent way across different web sites and environments.  In other words, reusable identities, the claims-based architecture, and truly usable and intuitive visual interfaces.

My Twitterank is 101.54

In case you need mind-stretching with regard to credulity, try out this piece from Sprout Marketing:

Madness erupted on Twitter last night, as the latest cool “app,” Twitterank, was suddenly accused of being a simple password swiping scheme. Over the past 48 hours, thousands of people were Tweeting the same message:

my Twitterank is 101.54!

Each one of those thousands of users freely gave out their username and password to the site. In exchange, the site uses some complicated algorithm (or not, maybe it&#39s entirely random) and out pops a rating.

Then around 3 p.m. or so, Mountain Time, PANIC broke out.

This is how e-riots start...

Within minutes, similar messages were everywhere. This is the online equivalent of an angry, confused mob [FOLLOW the incredible link – Kim] . ZDnet jumped in, along with dozens of other legitimate news sources.

News is breaking out this morning that it really isn&#39t a scam at all. Regardless, I think there are a couple lessons here.

1. Twitter people need to be a lot more careful about their passwords. A lot of them use the same passwords across multiple sites. If the Twitterank person wanted, he could be posting to your blog while ordering expensive popcorn with your credit card.

2. How trustworthy is your brand? Do people have confidence in coming to your site that if they share personal information, it&#39ll be protected? It took eBay and Amazon years to get to this point; they were the pioneers. There are tons of sites that do e-commerce now, thanks to Amazon.

Then you look at the Twitterank site; does it instill confidence? Kind of reminds me of an old Yahoo! Geocities page. Sure, he did it late one night for kicks, and he SAYS he won&#39t take your password…

Apparently this was good enough for tons of people. But I bet they&#39re rethinking that today.

The average person has no way of evaluating the extent to which their passwords are in danger, especially when presented with two related sites that perform redirection or ask for entry of passwords. 

The only safe solution for the broad spectrum of computer users is one in which they cannot give away their secrets.  In other words:  Information Cards (the advantage being they don&#39t necessarily require hardware) or Smart Cards.   Can there be a better teacher than reality?

[Via Vu – Thanks]

Jerry Fishenden in the Financial Times

It&#39s encouraging to see people like Jerry Fishenden figuring out how to take the discussion about identity issues to a mainstream audience.  Here&#39s a piece he wrote for the Financial Times:

Financial times

If you think the current problems of computer security appear daunting, what is going to happen as the internet grows beyond web browsing and e-mail to pervade every aspect of our daily lives? As the internet powers the monitoring of our health and the checking of our energy saving devices in our homes for example, will problems of cybercrime and threats to our identity, security and privacy grow at the same rate?

One of the most significant contributory causes of existing internet security problems is the lack of a trustworthy identity layer. I can’t prove it’s me when I’m online and I can’t prove to a reasonable level of satisfaction whether the person (or thing) I’m communicating or transacting with online is who or what they claim to be. If you’re a cybercrook, this is great news and highly lucrative since it makes online attacks such as phishing and spam e-mail possible. And cybercrooks are always among the smartest to exploit such flaws.

If we’re serious about realising technology’s potential, security and privacy issues need to be dealt with – certainly before we can seriously contemplate letting the internet move into far more important areas, such as assisting our healthcare at home. How are we to develop such services if none of the devices can be certain who or what they are communicating with?

In front of us lies an age in which everything and everyone is linked and joined through an all pervading system – a worldwide digital mesh of billions of devices and communications happening every second, a complex grid of systems communicating within and between each other in real time.

But how can it be built – and trusted – without the problem of identity being fixed?

So what is identity anyway? For our purposes, identity is about people – and ”things”: the physical fabric of the internet and everything in (or on) it. And ultimately it’s about safeguarding our security and privacy.

If we’re to avoid exponential growth of the security and privacy issues that plague the current relatively simple internet as we enter the pervasive, complex grid age, what principles do we adhere to? How can we have a secure, trusted, privacy-aware internet that will be able to fulfil its potential – and deserve our trust too?

The good news is that these problems are already being addressed. Technology now makes possible an identity infrastructure that simultaneously addresses the security and public service needs of government as well as those of private sector organisations and the privacy needs of individuals.

Privacy-enhancing security technologies now exist that enable the secure sharing of identity-related information in a way that ensures privacy for all parties involved in the data flow. This technology includes ”minimal disclosure tokens” which enable organisations securely to share identity-related information in digital form via the individuals to whom it pertains, thereby ensuring security and privacy for all parties involved in the data flow.

These minimal disclosure tokens also guard against the unauthorised manipulation of our personal identity information, not only by outsiders such as professional cybercrooks but also by the individuals themselves. The tokens enable us to see what personal information we are about to share, which ensures full transparency about what aspects of our personal information we divulge to people and things on the internet. This approach lets individuals selectively disclose only those aspects of their personal information relevant for them to gain access to a particular service.

Equally important, we can also choose to disclose such selective identity information without leaving behind data trails that enable third parties to link, trace and aggregate all of our actions. This prevents one of the current ways that third parties use to collate our personal information without our knowledge or consent. For example, a minimal disclosure token would allow a citizen to prove to a pub landlord they are over 18 but without revealing anything else, not even their date of birth or specific age.

These new technologies help to avoid the problem of centralised systems that can electronically monitor in real time all activities of an individual (and hence enable those central systems surreptitiously to access the accounts of any individual). Such models are bad practice in any case since such central parties themselves become attractive targets for security breaches and insider misuse. Centralised identity models have been shown to be a major source of identity fraud and theft, and to undermine the trust of those whose identity it is meant to safeguard.

It is of course important to achieve the right balance between the security needs of organisations, both in private and public sectors, and the public’s right to be left alone. Achieving such a balance will help restore citizens’ trust in the internet and broader identity initiatives, while also reducing the data losses and identity thefts that arise from current practices.

Now that the technology industry is currently implementing all of the components necessary to establish such secure, privacy-aware infrastructures, all it takes is the will to embrace and adopt them. Only by doing so will we all be able to enjoy the true potential of the digital age – in a secure and privacy-aware fashion.

Crypto flaw + bad practices = need for governance

Speaking of issues of governance, the Register just brought us this report on a recent “archeological investigation” by Ben Laurie and Richard Clayton that revealed how a Linux security flaw left a number of OpenID sites vulnerable to attack:

“Slipshod cryptographic housekeeping left some OpenID services far less secure than they ought to be.

“OpenID is a shared identity service that enables users to eliminate the need for punters to create separate IDs and logins for websites that support the service. A growing number of around 9,000 websites support the decentralised service, which offers a a URL-based system for single sign-on.

“Security researchers discovered the websites run by three OpenID providers – including Sun Microsystems – used SSL certificates with weak crypto keys. Instead of being generated from billions of possibilities, the keys came from a a set of just 32,768 options, due to a flaw in the random number generation routines used by Debian. The bug, which has been dormant on systems for 18 months, was discovered and corrected back in May.

“Keys generated by cryptographically flawed systems still needed to be replaced even after the software was upgraded. But recent research by Ben Laurie of Google reveals that 1.5 per cent of certificates he looked at contained weak keys. Three OpenID providers (openid.sun.com, xopenid.net and openid.net.nz) were among the guilty parties.

“To exploit the vulnerability, malicious hackers would need to trick surfers into visiting a site impersonating a pukka OpenID provider. But faking digital certificate alone wouldn&#39t do the trick without first misdirecting surfers to these bogus sites. Dan Kaminsky&#39s recent discovery of a DNS cache poisoning flaw made it far more plausible to construct an attack that sent surfers the wrong away around the net&#39s address lookup system, potentially to a bogus Open site posing as the real deal.

“The security flaw meant that even cautious users who check SSL certificates were at risk of handing over their OpenID credentials as part of a phishing attack. Such an attack would take a lot of effort to pull off and would only yield OpenID login credentials, which aren&#39t especially useful for hackers and are difficult to monetise.

“Going after online banking credentials via a site that makes no attempt to offer up fake SSL certificates is a far more reliable moneyspinner, a factor that leads noted security researcher Richard Clayton to describe the attack as the “modern equivalent of a small earthquake in Chile”.

“Sun has responded to the issue by generating a new secure key, which reduces the scope for mischief but still leaves potential problems from the old key.

“More thoughts on the cryptographically interesting – though not especially life-threatening – flaw can be found in Clayton&#39s posting on Cambridge University&#39s Light the Blue Touchpaper blog here. A security advisory by Laurie and Clayton explaining the issue in greater depth can be found here.”

I tip my hat to Ben and Richard for doing what I think of as “system archeology” – looking into the systems people actually leave behind them, as opposed to the ones they think they have built.  We need a lot more of this.  In fact, we need to have full time archeologists rigorously exploring what is being deployed.

This said, I have to question the surprisingly opportunistic title of Richard&#39s piece:  An insecurity in OpenID, not many dead.

Let&#39s get real.  None of what went wrong here was in any way specific to OpenID.  The weakness would have struck any application that relied on crypto and was built on Debian Linux and operated in the same way.  This includes SSL, which for some reason doesn&#39t get singled out.  And it applies to SAML, WS-Trust and PKI  (e.g. any of the security-based identity protocols).  Is OpenID a convenient straw man? 

In fact there were really two culprits.  First, the crypto flaw itself, a problem in Linux.  Second, the fact that although the flaw had been fixed, new keys and certificates had not been obtained by a number of the operators. 

So we are brought right back to the issue of governance, and in all fairness, Richard makes that point too.  Given the improper operating practices, and the fact that OpenID imples no contractual agreement, how would anyone have been able to sort out liability if the flaw had resulted in a serious breach?

Clearly, timely patching of one&#39s operating system needs to be one of the host of requirements placed on any identity provider.  A system of governance would make this explicit, and provide a framework for assigning liability should the requirement not be met.  I really think we need to move forward on a broadly inclusive governance conversation.

And finally, just so no one thinks I have gone out of character, let&#39s all note that any user who employed an Information Card to authenticate to the OpenID provider would NOT have had her credentials stolen, in spite of the vulnerability Ben and Richard have documented.   

 

Not the browser!

Google&#39s Ben Laurie bookends our dialog (work back from here) with a really clear statement:

Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.

Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.

This sounds really positive.  Now, just so I don&#39t end up with a different security product from every big web site, I hope Ben&#39s work will include integration with the CardSpace framework.  I&#39m certainly open to discussions about ways we might evolve CardSpace to facilitate this.

Ben Laurie&#39s “Single Passwords”

Given his latest post, I guess I got the gist of Ben Laurie&#39s proposal for using what I&#39ll call “Single Passwords” rather than “Single Signon”:  

“Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows).

Wow.  I appreciate the blessing from Father Laurie, but this is kind of a “We&#39re going to die one day, so who cares if we die tomorrow?” type of argument – surprising for a priest. 

While it&#39s true that pharming is a challenge for the operating system as well as the browser, let&#39s not seriously equate the dangers of entering passwords into browsers (a malleable experience, the goal of which is to be infinitely and easily modified by anyone) with those involved in booting up your PC (a highly controlled environment designed to allow no modification and use a secure desktop).  It&#39s true that both involve passwords.  But the equation is simplistic, best summed up as: “Tables have legs, people have legs, therefore tables are people.”

Anyway, I&#39m sympathetic to Ben&#39s concerns about portability:

“Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password.

I don&#39t dismiss dreamland – isn&#39t that what iPhones want to be?  But we do need lightweight roaming.  Using an online vault secured by a passphrase is a reasonable way to bootstrap a secret onto a machine.

But not the browser! 

The rub is:  once a user gets into the habit of typing this secret into the browser, she&#39s ready to be tricked.  I&#39ll go further.  If  the vault one day accrues enough value, a browser-based system WILL fail the user – sooner or later.   

Ben concludes:

“If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?

“If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?”

There&#39s food for thought here.  Start to take advantage of the engineering in CardSpace, and you inherit significant protection in terms of both phishing and pharming.  So if Ben implements his “Single Password” this way, he could start to be reasonably confident that the “function of the password” is what is released, while the password is guarded.

Understanding Windows CardSpace

There is a really wonderful new book out on digital identity and Information Cards called “Understanding Windows CardSpace“. 

Written by Vittorio Bertocci, Garrett Serack and Caleb Baker, all of whom were part of the original CardSpace project, the book is deeply grounded in the theory and technology that came out of it.  At the same time, it is obviously their personal project.  It has a personal feeling and conviction I found attractive.

The presentation begins with a problem statement – “The Advent of Profitable Digital Crime”.  There is a systematic introduction to the full panoply of attack vectors we need to withstand, and the book convincingly explains why we need an in-depth solution, not another band-aid leading to some new vulnerability.

For those “unskilled in the art”, there is an introduction to relevant cryptographic concepts, and an explanation of how both certificates and https work.  These will be helpful to many who would otherwise find parts of the book out of reach.

Next comes an intelligent discussion of the Laws of Identity, the multi-centered world and the identity metasystem.  The book is laid out to include clever sidebars and commentaries, and becomes progressively more McLuhanesque.  On to SOAP and Web Services protocols – even an introduction to SAML and WS-Trust, always with plenty of diagrams and explanations of the threats.

Then we are introduced to the concept of an identity selector and the model of user-centric interaction.

Part two deals specifically with CardSpace, starting with walk-throughs, and leading to implementation.  This includes “Guidance for a Relying Party”, an in-depth look at the features of CardSpace, and a discussion of using CardSpace in the browser.

The authors move on to Using CardSpace for Federation, and explore how CardSpace works with the Windows Communication Foundation.  Even here, we&#39re brought back to the issues involved in relying on an Identity Provider, and a discussion of potential business models for various metasystem actors.

Needless to say, much of what&#39s covered in this book applies to Higgins and OpenInformationCard and Bandit as well as CardSpace. 

Above all, it is a readable book that balances technology with the broader issues of identity.  I imagine almost anyone who reads this blog will have something to gain from it.  I especially recommend it for people who want a holistic introduction to digital identity, CardSpace and web services.  I think the book is excellent for students.  I even expect it will be enjoyed by more than one policy maker who wants to understand the underlying technical problems of identity.

So check it out, and let me know what you think.

[By the way:  One chapter of the book is now online as a stream of html text, but I&#39d avoid it. The printed layout and interplay of commentaries add both life and interest…]

Ready or not: Barbie is an identity provider…

From Wired&#39s THREAT LEVEL, news of an identity provider for girls.

Just today at the CSI Conference in Washington, DC, Robert Richardson was saying he saw signs everywhere that we were “on the cusp of digital identity truly going mainstream”.  Could anything be more emblematic of this than the emergence of Barbie as an identity provider?  It&#39s really a sign of the times. 

From the comments on the Wired site (which are must-reads), it seems Mattel would be a lot better off giving parents control over whitelist settings (Law 1:  user control and consent).  It would be interesting to review other aspects of the implementation.  I guess we should be talking to Mattel about support for “Barbie Cards” and minimal disclosure…  I certainly tip my hat to those involved at Mattel for understanding the role identity can play for their customers.

At last, a USB security token for girls! 

Pre-teens in Mattels’ free Barbie Girls virtual world can chat with their friends online using a feature called Secret B Chat. But as an ingenious (and presumably profitable) bulwark against internet scum, Mattel only lets girls chat with “Best Friends,” defined as people they know in real life.

That relationship first has to be authenticated by way of the Barbie Girl, a $59.95 MP3 player that looks like a cross between a Bratz doll and a Cue Cat, and was recently rated one of the hottest new toys of the 2008 holiday season.

The idea is, Sally brings her Barbie Girl over to her friend Tiffany&#39s house, and sets it in Tiffany&#39s docking station — which is plugged into a USB port on Tiffany&#39s PC.  Mattel&#39s (Windows only) software apparently reads some sort of globally unique identifier embedded in Sally&#39s Barbie Girl, and authenticates Sally as one of Tiffany&#39s Best Friends.

Now when Sally gets home, the two can talk in Secret B Chat. (If Sally&#39s parents can&#39t afford the gadget, then she has no business calling herself Tiffany&#39s best friend.)

It&#39s sort of like an RSA token, but with cute fashion accessories and snap-on hair styles. THREAT LEVEL foresees a wave of Barbie Girl parties in the future, where tweens all meet and authenticate to each other — like a PGP key signing party, but with cupcakes.

Without the device, girls can only chat over Barbie Girls’ standard chat system, which limits them to a menu of greetings, questions and phrases pre-selected by Mattel for their wholesome quality. 

In contrast, Secret B Chat  lets girls chat with their keyboards — just like a real chat room. But it limits the girl-talk to a white list of approved words. “If you happen to use a word that&#39s not on our list (even if it&#39s not a bad one), it will get blocked,” the service cautioned girls at launch. “But don&#39t worry —  we&#39re always adding cool new words!”

By the way, Kevin Poulsen has to get the “High Tech Line of the Year Award” for “a PGP key signing party, but with cupcakes.”  Fantastic!

[Thanks to Sid Sidner at ACI for telling me about this one…]

Assurance about what?

I&#39m facinated by this post by Pamela Dingle at Adventures of an Eternal Optimist:

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.

I would put it this way.

  • Self-issued cards provide high assurance that the subject possesses the key associated with the card.  In other words, the key is itself a claim, and self-issued cards  intrinsically offer high assurance of the validity of this claim.  This may not sound big, but it&#39s a big deal, since it is the essence of interactive authentication.  However, other self-asserted claims require out-of-band verification if certaintly is required.
  • Managed cards can provide various degrees of assurance around a broad set of claims.   In this case, an out-of-band process is required to establish what claims should be accepted from a given identity provider.

Sorry.  As Pam says, assurance isn&#39t binary.