About The Blog

Debate at the intersection of business, technology and culture in the world of digital identity, both commercial and government, a blog born from the Digital Identity Forum in London and sponsored by Consult Hyperion



  • Add to
Technorati Favorites


  • Creative Commons

    Attribution Non-Commercial Share Alike

    This work is licensed under a Creative Commons Attribution - Noncommercial - Share Alike 2.0 UK: England & Wales License.

    Please note that by replying in this Forum you agree to license your comments in the same way. Your comments may be edited and used but will always be attributed.

« Law 2.5 or 3.0 or whatever | Main | Things aint what they used to be »


By Dave Birch posted Jul 12 2010 at 2:11 PM

[Dave Birch] It's taken me a while to sit down and read through the US Government's National Strategy for Trusted Identities in Cyberspace (USTIC) paper that is out for comment. I've tried not to read it just as a technical expert (what do they mean by strategy? what do they mean by trust? what do they mean by identity? what do they mean by cyberspace?) but as someone who wants to see real change in the identity landscape and a step change in the security of online transactions. Can the USTIC help this agenda? The document says early on that it is about a user-centric identity ecosystem, a world-view that I entirely support, so let's take a look.

One not entirely trivial point before we start: one thing that did annoy me about the document was that it uses the phrase "digital identity" to mean what I would call a "virtual identity". That is, it defines a digital identity as the set of attributes that represent an individual in a transaction, whereas I would define the virtual identity as the set of attributes that represent a digital identity in a transaction because it is the digital identity that is the bridge between the real and virtual worlds, the connection between individuals and what the US strategy calls "non-person entities" and their representation in electronic form. (I can see I'm losing this battle, but I'm not going to give up easily.) So I'm going to use my (more precise) terminology in discussing the strategy.

The document describes an identity ecosystem for use by individuals, business and government that attempts to balance the requirements for identification and "reputation" in a forward-looking manner. It talks about creating a user-centric identity ecosystem, which it defines as an ecosystem that will allow individuals to select the interoperable credential appropriate to a specific transaction. In other words, it lets people select between different virtual identities on a per transaction basis, something that we have long advocated. Now, obviously, the individual's choice of credential cannot be entirely unconstrained. I can well imagine being allowed to log in to Citibank using a Barclay's Bank identity but not being allowed to log into Citibank using, say, my Twitter login. Similarly, I can well imagine using my Facebook identity to get access to some basic government information about benefits but having to use my mobile phone in someway to confirm my identity to log in to obtain, let's say, the results of the medical test -- more on this example later.

I emphasised this last example, by the way, in the light of the news that PayPal and Microsoft are already conducting an "identity mash up" with a medical company.

Medtronic, PayPal, Southworks, and Microsoft recently worked together to demonstrate the ability for people to use their PayPal identities for participating in a Medtronic medical device trial, rather than having to create yet another username and password... the name, address, birth date, and gender claims provided by PayPal are relied upon by Medtronic and its partners as being sufficiently authoritative...

[From Mike Jones: self-issued » Using Consumer Identities for Business Interactions]

From the point of view of the UK, where the national identity card scheme has just been scrapped and there is no alternative identity infrastructure in place, there is much to be admired in the US approach. The idea of creating an ecosystem that is built around the idea of public and private sector co-operation, individual choice, opportunities for innovation and market-based practicality should be a matter of priority here as well because if it is not, then efforts such as Martha Lane Fox's Manifesto for a Networked Nation will remain gimmicks: what's the point of making the population use the web if they can't do transactions?

Government should “think internet first” in designing services and provide support for those who need help using its online services.

[From David Cameron Supports Digital Champion’s Ambition – Make UK First Nation Where Everyone Can Use the Web « Raceonline2012's Blog]

Right now, I can't even use the same login identity for the DVLA and HMRC (the only two online government transactions I ever do).

Personally, I might take a slightly different approach to setting out the challenges and options because I come from a more technical background. Whenever I read something about these issues I always want to know what the underlying model of identity, authentication and management actually is. When someone tells me about authenticated access to a service, I can't help but wonder what they mean in terms of keys and certificates, devices and interfaces. This means that I start to think about the practical structure that is implied.

The structure envisaged in the US strategy, rather like the structure presented by Innopay at the recent "Identity is the New Money" session that we contributed to at the European eID Management conference (they presented a study they had done for the Dutch government which came to a similar conclusion as to the necessary structure), is a four party model much like the payment card model where there are consumers, relying parties (taking the role of the merchant in the payment card model) and the issuing and acquiring "banks" (which may well be, in my opinion, banks).

In order to obtain some interoperability between the issuers and the acquirers you need the equivalent of payment schemes to set out the interoperability rules, as Identrust has done in the corporate banking space. Some time ago when Consult Hyperion was asked to study the issue of electronic ID interoperability in pan-European environments we identified the equivalent three levels of interoperability to those that the US strategy uses. These are: technical interoperability, semantic interoperability and policy interoperability. Of these, technical interoperability turns out to be not that complicated. Yes there are issues, but these are issues that can be resolved by technical people working together and there are plenty of such people who understand everything from web services to open authentication to public key infrastructure (PKI) to smart cards and so on. Semantic interoperability, on the other hand, turns out to be quite hard because it is very difficult to find machine-readable methods for communicating the meaning of identity constructs. It's one thing to be able to read an Estonian driving licence but quite another to understand the conditions under which Estonian driving licences are issued. And as you might imagine, policy interoperability is intractably complicated because it lays outside the boundaries of the technology. So there are real issues here and we cannot just take interoperability as given.

I did note with interest that when talking about making the identity ecosystem both cost-effective and easy to use, the document refers to mobile phones as the mechanism for achieving both. We have been advising our customers of this approach for many years and anyone who has read the Digital identity Forum blog for any length of time will have become almost catatonic with boredom at my constant complaining about the ID card and web focus of many of the UK's initiatives and discussions. "Digital Britain" is a case in point, since for the great majority of people it will be mobile phones and digital TV that ought to provide the services that they need. Therefore, a working identity ecosystem must be about something more than logging in to DirectGov over the web, which is not to say that logging on to DirectGov securely and easily isn't important. It is.

But I digress (again).

The document envisages the ecosystem being set up in three layers that exploit the interoperabilities mentioned before. So there is an execution layer where the online transactions that use virtual identities take place, a management layer where the virtual identities are created (in my model, this would be achieved by binding credentials to digital identities) and above a governance layer where the rules about trust in virtual identities are established and maintained.

To see what this means, consider the relatively simple example given in the document. I have a digital identity in my phone, at the hospital this is bound with some credentials (perhaps some hospital identifier, insurers' identifiers or whatever) to form a virtual medical identity that can be used in the relevant medical contexts. I now go to a hospital website to view my wife's test results, something that the management layer has determined to be acceptable. You could imagine the hospital record having pointers to both my medical identity and my wife's medical identity (these are virtual identities, remember, so their attributes need not include, for example, real names). The test results are encrypted for my medical identity, which at the transaction layer means that the public key from my medical identity is used to encrypt a session key that has been generated for that specific transaction (of viewing the test results). The test results are sent back to me and (under the hood) the encrypted session key is sent to my mobile phone for decryption using the relevant private key (which never leaves the tamper-resistant SIM in my phone). Naturally I am then prompted to enter some pin or password into my phone.

Now this may seem a little complicated when you set the steps out in this kind of detail, but this is exactly how financial transactions with Garanti bank in Turkey are authenticated using the Turkcell mobile PKI system or how financial transactions with DNB NOR are authenticated using BankID. It's a small step from these implementations to the more flexible environment envisaged in USTIC whereby arbitrary virtual identities can be bound to the SIM-based digital identities. These steps must be made, because one-factor authentication (ie, passwords) is not sufficient to provide access to valuable services of any kind. But suppose you had an option to switch your Facebook account to 2FA and then log on to your bank and bind your bank details to that Facebook account: then why shouldn't you do a 2FA Facebook log on to access your bank?

I agree with the document drafters that this type of implementation provides a platform to innovation that will open up some really new thinking and lead to significantly better ways of interacting online. There are many ways this ecosystem could be used: just as I can imagine the VRM implementation whereby the hospital subscribes to a data feed from my medical identity, so that wherever credentials associated with that medical identity change they are fed out on the feed encrypted using the hospitals medical identity (remember non-person entities have virtual identities too!) so I can imagine that the hospital may allow me to subscribe to a feed of test results that are private to my medical identity (and my wife's medical identity, of course).

I must conclude with a note of very slight pessimism on timescale, however. It's very easy to say that the public and private sector will work together to realise this identity ecosystem vision but I have no reason to suspect that the involvement of the federal government, nor its high-level commitment, will help us to get over some of the biggest barriers and that's because the issue of trust takes us into legal territory and this is of course the reef on which any new technology ship can founder.

When I used the medical example above I said glibly that I would obtain the test results from the hospital private to my medical identity and that the hospital would obtain data from me private to its medical identity. But how do I know that the medical identity that I am presented with is genuinely the hospital's medical identity? In the traditional PKI environment the way that this knowledge is spread is through directories so my web browser has to be able to go somewhere to obtain the hospital's medical identity which is, you'll remember, the hospital's public key signed by some else's private key. So I need the certificate for this someone else, and so on until we get to the "root". As anyone who has tried to use secure e-mail recently knows, this is a nightmare despite every e-mail package having S/MIME built in as standard. But suppose we get it all working? Then we still don't have a trust infrastructure until the legal agreements are in place as well: suppose that it isn't the hospital, or the bank, of the Department of Defense on the line, then who do I sue?

A final point. The Identity Woman noted, in her review of the same document, that

Sounds like they get what verified anonymity is and how it means that people don’t have to share all their information when doing transactions online.

[From Identity Woman » Thoughts on the National Strategy for Trusted Identities in Cyberspace]

I agree, but I would like to see this more central in the strategy. In fact, if there were to be a UK version of this, I would like it to take multiple pseudonymous identities as the norm and make the use of "absonyms" the exception. People should consider it normal to get a virtual identity from their bank or their mobile phone operator in a pseudonymous name so that they can browse, transact and comment without revealing anything about themselves other than the facts relevant to a transaction. This would be progress.

These opinions are my own (I think) and presented solely in my capacity as an interested member of the general public [posted with ecto]


TrackBack URL for this entry:

Listed below are links to weblogs that reference USTIC:


The comments to this entry are closed.