Tag: identity management

The WEF blueprint for digital identity – the middle way

18th August 2016by Consult Hyperion3 Comments

The World Economic Forum (WEF) has just published their report on “A Blueprint for Digital Identity”. It begins with a disclaimer from “Deloitte”* saying that “This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business”. But what’s the point of reading a report that isn’t going change any decision or action that you make? I think quite the opposite: you should read the document and make the decision to have a strategy towards digital identity and start to explore different scenarios covering how it will affect your business right away.

First, let me admit that I was excited to see that WEF/Deloitte* have finally caught up with Consult Hyperion’s thinking on this kind of thing. Back in 2008, I wrote that:

Banks ought to be looking at both providing and consuming identity services and developing better identity and authentication services not merely for their internal use to reduce phishing and pharming but as a line of business in an online society. They are the obvious category of institution to provide credentials, manage personal information and deliver identity into the marketplace.

From Digital Identity: I’m sure banks have a strategy for this kind of thing

The WEF report says that “There is a strong business case for Financial Institutions to lead the development of digital identity systems” and goes out to categorise these are cost reduction, new revenue opportunities and transformational new models (i.e., outside core banking). I agree that it’s important to look at the saving money and making money opportunities in this way because in any bank that I’ve spoken to about this sort of thing, it’s been clear that the saving money business case has to stack up before there will be any investment.

As for the blueprint, the report suggests three approaches, – the institution, the consortium, the industry – which I paraphrase here:

A single institution could create its own system, focusing on cost saving but with limited potential for further adoption (but I think ”ChaseID” would struggle against “AppleID”);
A consortium could create a co-opetition infrastructure along the lines of the payment networks (some sort of financial services passport);
The financial services sector as a whole could create some form of industry identity utility that could be used to deliver “wholesale” identity services (I could get gas, electricity and identity all from the same retailer);

I’m rather in favour of the middle option as I think it delivers immediate improvements to the day-to-day transactions of modern life and it is, above all, feasible. But what exactly would it implement? The model of identity transactions that the WEF present (page 43), which divides identity transactions into authorisation, attributes and authentication is I think a little too narrow. The model we use at Consult Hyperion (“Three Domain Identity”, or 3DID) provides a better platform for discussion and exploration (but then I would say that wouldn’t I) because it makes the relationships between identities, attributes, credentials and so on more explicit.

When it comes to discussing archetypes (or “marketectures”) that will make sense (page 62), the use of the 3DID model makes it easier to understand the different options but considering who will control each of the domains. If, as WEF recommend, it is the financial institutions who control the Digital Identity and they link this to a variety of Mundane Identities from different sources and well as to a potentially large numbers of Virtual Identities (where credentials are held, essentially) it gives them a pivotal role. This might be in a federated structure, where each banks holds its own KYC and makes it available to other banks, or some other options. However it’s done, the authentication (proving you control the digital identity) is another matter.

One of the reason why I have such an interest in the “middle way” WEF blueprint is that I’ve been part of a techUK working group looking at this since 2014.

A ‘financial services passport’ refers to an aspirational digital identity, issued by UK financial services providers, and mutually recognised across the financial services industry.

From Workshop: Towards a Financial Services Passport

Such a passport would not only be used for financial services and for the benefit of financial institutions. It could be used to improve all sorts of services that desperately need a proper identity infrastructure. It could with internet dating, protecting people on twitter from trolls, access to adult services and other “sharp end” applications of digital identity that would be transformational not only for bank revenues but also for consumers in the mass market. The solutions to the big, immediate problems in these areas come not from the digital identity itself but from the virtual identities built on top of it, because the virtual identities are a way to communicate attributes rather than identity.

So what might banks do with your identity once they’ve got it safely locked away in their vaults? Well, one idea, particularly popular with me, is that they might give you a safe, pseudonymous virtual identity to go out an about with.

From Tired: Banks that store money. Wired: Banks that store identity | Consult Hyperion

The idea of strong pseudonymity is particularly appealing: a pseudonymous virtual identity with a bundle of credentials attested to by regulated financial institutions should be more than enough for almost all day-to-day transactions. This would allow for a new tranche of what economists call “incentive functions” to be created by banks, encouraging transactions where none would have taken place otherwise.

But back to the WEF report. In conclusion, despite my preference for our model (!), when it comes down to it, I think that the middle way (the consortium approach) is the place to start and I strongly agree with the principal recommendation of the report, which is that (page 101) “Implementation of a digital identity system should follow a bottom-up approach”. What the WEF calls “natural identity networks” I might be very tempted to label”communities”. So let’s create identity solutions for communities (starting with the financial services passport for the retail financial community of customers, providers and regulators) and find ways to interconnect them rather than trying to think up some kind of top-down “World ID” for the communities to implement.

* “Deloitte” refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients.

Tired: Banks that store money. Wired: Banks that store identity

28th June 2016by Consult Hyperion

Speaking at the Dutch National Blockchain Conference back in June, I remarked in passing that I thought bank customers would be storing their money (their wealth) in all sorts of places in the future – from a small percentage in demand deposit accounts, through investment accounts of one form or another, P2P marketplaces and who knows what – but that they would be storing their identity back at the bank.

This was picked up on Twitter and a few people commented on it, so I thought I’d expand on what I meant here. First of all, it is neither a new idea nor my idea: other people have been saying this and they’ve been saying it for a while. I might have expressed it in a better soundbite, but it isn’t my concept.

Britain’s high street banks believe their future role will be as repositories of more than just money: they want to be the safe place where customers store their digital identities.
[From Banks want to keep your digital ID in their vaults – FT.com]

That’s from a couple of years ago. It is not some out-of-left-field edge thinking or me spouting aphorisms for a conference stream either. Round about this time, the European Banking Association (EBA) said something similar and you can’t get much more mainstream than them.

Banks are well positioned as is explained in a recent white paper of the European Banking Association (EBA).
[From Digital Identity: how banks can position themselves in their customer’s online lives | Innopay]

So what might banks do with your identity once they’ve got it safely locked away in their vaults? Well, one idea, particularly popular with me, is that they might give you a safe, pseudonymous virtual identity to go out an about with.

Some suggest that digital identity verification by banks could ultimately end the need to type in a credit-card number on an ecommerce website
[From Banks want to keep your digital ID in their vaults – FT.com]

Some others (uncharitable persons, of which I am not one) also suggest that banks will pratt about and muck this all up and hand digital identity ownership over to Apple, Facebook, Google, Amazon and Microsoft on a plate. But if banks were to develop some common strategy around this topic (perhaps related to the financial services passport concept that’s been discussed here before) then where should they start?

Well, what about the “adult identity”? Why doesn’t my bank put a token in my Apple Pay that doesn’t disclose my name or any other personal information, a “stealth card” that I can use to buy adult services online using the new Safari in-browser Apple Pay experience? This would be a simple win-win: good for the merchants as it will remove CNP fraud and good for the customers as it will prevent the next Ashley-Madison catastrophe. Keep my real identity safe in the value, give me blank card to top shopping with – a simple use case that will test the viability of the concept.

Putting “identity” on the “blockchain”. Part 4: Create a ledger of transactions

9th June 2016by Consult Hyperion

Okay let’s continue the experiment of thinking out loud about putting “identity” on the “blockchain”. Just to recap, in Part One we identified a specific identity problem that might be solved using shared ledger technology, in this case the problem of KYC for financial services. In Part Two we identified a useful and consistent model for digital identity that seemed powerful enough to encapsulate a solution to the problem. In Part Three we worked out which identity transactions we wanted to store in our shared ledger, and we decided that the history of transactions involving a particular virtual identity could serve a useful function as the reputation of that identity. Today, will move the thought experiment on to actually implementing the shared ledger.

Now without thinking about it for too long, it seems to me that there are three options for implementing the Shared Ledger of Identity Transactions that we intend to use to facilitate reputation-based interactions. Let’s call this the SLIT for short. We could implement the SLIT using conventional database technologies and either construct a centralised database for all financial services participants to share all we could have databases held by financial services participants interoperable through some form of federation, as we discussed in Part One. However, as I will return to the end of this piece, that implementation wouldn’t give us access to the likely source of genuine revolution in this space, which I think is the use of shared ledger applications (otherwise known as “smart contracts”) to deliver radically new products and services. Hence, I think we should dismiss the traditional implementation and look at implementations based on the new generation of shared ledger technologies.

I can see two ways of doing this. First would be to implement the SLIT using any one of a number of Practical Byzantine Fault Tolerant (PBFT) technologies that are out there right now. The other possibility, rather as Blockstack have done, is to implement the SLIT as a virtual ledger and build the applications on top of that, then map the virtual ledger to an actual ledger implementation. I tend to favour this latter approach, for the simple reason that it is not at all obvious to me (with the obvious caveat that I know literally nothing about cryptography) which is the best shared ledger implementation. It could be that implementing the virtual ledger on the Bitcoin blockchain is the best possible way of doing things (as shown in the diagram below). On the other hand, it could be that implementing the virtual ledger on an Ethereum blockchain built specifically for the purpose is the best way forward. On the other hand, it may be that not using a blockchain at all and implementing the virtual ledger on some other PBFT platform is the best way forward. As any of our consultants would say when dealing with this problem for a client, it depends. Until we know what the prioritised requirements, constraints and goals for the system are is not possible to say which is the best solution.

So let’s go down this route. We define the SLIT and agree who has access to the SLIT. We define the financial services passport that we spoke about in Part One as a particular kind of virtual identity with some agreed fields. Now we can see how it might work in practice. I go to my bank to open a bank account. The bank does all of the necessary KYC checks and creates a digital identity. The private key associated with this identity is stored safely in the bank and a copy is downloaded to the bank application on my phone and safely tucked away in tamper-resistant memory (inside the SIM card or the secure enclave or wherever). The bank creates a virtual identity using the public key from the digital identity and adds a set of standard fields (name, address and so on and so forth) as required by the regulators. It then adds a digital signature using its own private key. A pointer to this virtual identity along with necessary descriptors is then added to the SLIT.

Now imagine that I go to appoint a new financial adviser. A financial adviser needs to see my financial services passport so I run the bank app my phone and select the option to provide my identity or however the marketeers dress it up. A copy of the ledger entry is sent to the financial adviser. Now he or she (or more likely their app) can go to the SLIT and look at all subsequent entries for that same virtual identity (in particular to see whether it has been revoked or not). The virtual identity looks okay, so now the financial adviser needs to know that the virtual identity belongs to me so his app takes the public key from virtual identity, encrypts a challenge and sends it to my app which decrypts it (because it has the associated private key) and responds. Now the financial adviser can either use that virtual identity or in the more general case use it to generate a financial advice virtual identity which is then stored in the ledger itself.

All of the financial services participants in this ledger can now have access to all of the virtual identities. I think, although I may need to think about this more! Anyway, we now have a problem, an identity model, identity transactions and a ledger to store them in. We’re nearly there.

What is crucial is to implement the virtual ledger using a technology that allows for shared ledger applications, and this is where we’ll continue with the final part of our thought experiment tomorrow.

Putting “identity” on the “blockchain”. Part 3: Define the transactions

8th June 2016by Consult Hyperion1 Comment

Now onto part three of our week of thinking out loud about putting identity on the blockchain. In part one we found a problem that could be solved using some kind of identity infrastructure. In part two we came up with a model of digital identity that we could use to explore a potential solution to this problem. Now, we are going to think about how that model could connect with some kind of shared ledger in general and with a blockchain or, indeed, the blockchain.

Our starting point is to observe, as my colleague StevePannifer said in his presentation at the Cloud Identity Summit in New Orleans this week, a ledger is a record of transactions. Therefore, we must think about the identity transactions implied by the model that we looked at in part two before we start to think about how to store them in a shared ledger. We start by observing that identity transactions are the “CRUD” (that is the Creation, Reading, Updating and Deleting) of identities. Since our model includes three kinds of identities it admits the possibility of three distinct sets of CRUD transactions that might be stored in the shared ledger as shown in the picture below.

The first category relates to the mundane identity CRUD of people, things and organisations. We could take some physical characteristic of these such as a fingerprint, a photograph or a serial number and store these in a shared ledger. This may be a good thing to do, but my first thought about this is that actually we probably want to avoid storing such things in the ledger or at the very minimum storing them in unencrypted form. I have to spend some time thinking this through, but it’s not immediately obvious to me that storing the binding between the digital identity and the mundane identity on the ledger moves us forwards.

The second category relates to the digital identity CRUD. Remember from part two that I am imagining the digital identity as being, essentially, a key pair. We need to store the private key somewhere safe and provide an authentication mechanism so that control over the digital identity can be asserted. Then we need to provide the public key for a variety of uses. Now, a key pair sounds very much like a wallet on a block chain and it is certainly a plausible hypothesis that this could be an implementation of digital identity. However it suffers from the same general category of problem as does cryptocurrency, which is the problem of the storage and protection of the private key. Either you have to look after the private key yourself, which is a degree of responsibility that I for one am most unwilling to accept, or you have to trust somebody else to look after the private key for you (e.g. your bank).

In practice, this would mean that the key pair is held by some third-party and while the idea of having sovereign control of your digital identity in some sort of blockchain is an appealing prospect if you are a 20-year-old computer science major MIT, I remain unconvinced that is a mass-market solution especially in developing countries. Here, I feel that the example of M-PESA (as we were discussing on Twitter yesterday) is illustrative. M-PESA, which was launched remember by a telco not by a bank, stores cryptographic keys in the tamper-resistant SIM in a mobile phone and this strikes me as being the plausible mass-market solution. In an M-PESA-like system, the SIM generates the key pair and gives up the public key but the private key is never disclosed. Uunfortunately this means that if you lose your SIM you may have messages that you can no longer read so we need a more sophisticated mechanism for a workable mass-market infrastructure!

The third category relates to the virtual identity CRUD. Remember in the model that I sketched out in part two, I made the assumption that all transactions are between virtual identities. Now the transactions associated with a virtual identity, if they were to be stored in a shared ledger, would then provide a record of that virtual identity’s activities. Those virtual identities need not identify the binding between the digital identity and the mundane identity. So, I could have a digital identity that I use for work and one for home and one for play. I use my play identity to obtain an adult identity from some grown-up website and that identity might well contain attributes that it has obtained from other credentials (that I am over 18, for example) but not my name.

Then the history of that virtual identity is in effect a kind of reputation. If you ask me for my reputation on some sharing economy platform, I can point you to a entry in the shared ledger. This gives you a public key. You can do two things with this key right away. First of all, you can use it to encrypt a challenge for me (because in order to answer the challenge I must have control over the corresponding private key). Secondly, you can look through the ledger to find transactions associated with that public key (to find out, for example, when the virtual identity was created) and whether is has been deleted.

You can also check the digital signature on the virtual identity to confirm who created it (i.e., was it really Barclays Bank or AirBnB or whoever).

The ability to check the reputation of a counterparty in this way seems to me to one of the fundamental benefits of such an identity infrastructure and central to a functioning online economy.

If I find a seller labelled as John Doe, I really have no interest in discovering their underlying identity: that takes time and effort. If there are positive comments about them from people whose opinion I value then I will do business with John Doe. If there are negative comments, then I won’t. And it won’t matter to me whether John Doe has badge from the local council, the government or some other body’s approval. My decision will be based not on what anyone thinks, but on what everyone thinks.

This comes from an article I wrote for “The Guardian” a fair few years ago (“Reputation not Regulation”, 2nd Nov. 2000, sadly longer online but you can download a PDF here). On this, I don’t think my opinion has changed much. The ideas that I was putting forward back then we constructed to support economic activity with both security and privacy as priorities. If anything, my views about building security and privacy into the identity infrastructure have become more entrenched since then.

Now, in the “old” PKI model, if I presented you with a virtual identity you would have to go to the issuer and check the certificate revocation list (CRL) or access an Online Certificate Status Protocol (OCSP) responder to see if it is still valid. In order to minimise the traffic, the issuers would basically need to issue virtual identities with short expiration dates which would mean people, organisations and devices constantly having to obtain new certificates. Now, this in itself is I think workable. But in the shared ledger version of this story, there is no need to query the issuer because the history of the virtual identity is in the ledger.

In the model we’ve been building up this week, then, reputation can be interpreted as the history of a virtual identity, the complete list of “CRUD” transactions stored in the shared ledger. Does this seem like a reasonable model to proceed? If so, tomorrow I’ll think out loud about how to implement the shared ledger for identity.

Putting “identity” on the “blockchain”. Part 2: Create an identity model

7th June 2016by Consult Hyperion2 Comments

I’m continuing my week of thinking out loud about identity on the blockchain. In Part 1, we came up with a real problem that needs fixing and explored the idea of a financial services passport. In Part 2, we’re going to put forward an identity model that could form part of solution to that real problem. The starting point for the thinking here is that as part of some recent work for a client, at Consult Hyperion needed to create a simple digital identity model to facilitate discussion around the provision of digital identity services to support financial services. In order to do this we revisited three basic concepts of identity infrastructure. These are the mundane identity (the “real world” physical entity that the digital identity is connected to), the digital identity itself and the virtual identities that are used to interact online (all transactions, in this model are between virtual identities).

The reason for this three part model for identity is that it is a fundamental rule of systems analysis, going back to the earliest days of data modelling, that you cannot have many-to-many entity relationships. Since there may be multiple physical entities relating to multiple virtual identities (an obvious example is a company, where a number of people have executive control over a number of virtual identities that are used to transact with other companies, government, regulators and so forth), we introduce digital identity as the linking entity to enable a workable identity management infrastructure.

This part of the model should be familiar. You probably read about it a few years ago in “A Model for Digital Identity” by Neil McEvoy and me in that indispensable tome “Digital Identity Management: Technological, Business and Social Implications“, edited by yours truly. (It’s on pages 95-104, for ready reference.) In that chapter, Neil and I put forward this idea of digital identity as the bridge between mundane and virtual identities for a variety of reasons anchored in the entity-linking structure, one of them being that the use of multiple pseudonymous virtual identities is a great way to move forward past some of the apparent paradoxes of identity and a great way to think about identity in an online world.

Anyway, I wanted to use this model to explore the issue of biometric authentication. This was because Isabelle Moeller from the Biometrics Institute (below centre) had kindly invited me to give at talk on the topic of biometrics and digital identity at their 2016 Asia-Pacific Conference in Sydney and then take part in a panel discussion with Victoria Richardson from APCA (who was unfortunately caught up in other things on the day but the excellent Nick Cliff stood in for her) and Mandy Smith from ANZ (below left). Since the audience would be mainly people with experience and interest in biometrics, I thought (correctly, as it turned out) that a simple of model of digital identity would be needed to anchor my talk and give context to the central part of the presentation, which was about biometrics as a convenience technology when combined with mobile as an authentication platform.

To make that simple model, I chose to map the three identity entities to three different domains where a binding is required (hence three domain digital identity, or “3D-ID”). You can see the three domains and the three bindings in the picture below. In the identification domain we do the complex and expensive binding of the person or organisation or thing to the digital identity. In the authentication domain we bind the digital identity to a person or organisation of thing that is entitled to use it. In the authorisation domain we bind the digital identity to the virtual identities that interact online to execute transactions. For the purposes of simplicity, think about the digital identity as a private-public key pair and think about the virtual identities as public key certificates that take the public key from the digital identity and link it to attributes to form credentials.

So who might be a provider of digital identity, given that the binding of digital identities to mundane identities is complex and expensive? Well, here’s what Neil and I wrote in the book nearly a decade ago:

One could certainly imagine niche identity issuers springing up across both horizontal and vertical sectors (the government, from this perspective, becomes a special case of a niche identity issuer) where economics or other pressures dictate.

An obvious case would be that of banks. Since they are already covered by “know your customer” (KYC) and other legislation, they are perfectly capable of issuing digital IDs that might be widely accepted. These and other digital IDs would then be used to create one or more virtual identities (eg, an employer creating an employee identity), most likely through brand-based businesses using white-label services.

To illustrate what we meant by this, think of the example of a dating site. The dating site needs to know that I am a real person, but it doesn’t need to know who I am. If it knows who I am, then it has a responsibility to look after my identity, which I’m sure it doesn’t want. I don’t want it either, because when the dating site is inevitably hacked I don’t want my identity smeared all over the web. So when I go to create my account at the dating site (in others words, when I go to create my dating virtual identity) I can present my bank virtual identity. The dating site forces an authentication (using, for example, FIDO) and once it gets the positive response it can then take the public key from the bank virtual identity, add attributes that it can attest to (e.g., date joined, name chosen, etc) and sign that with its own private key. This creates a new dating virtual identity at minimal cost. (We’’ return to the point abut correlating public keys across virtual identities when we come back to think more about implementations.) Take it from me, it all works, provided you have somewhere to store the private key. Sound familiar? Well, we’ll talk about digital identity and the blockchain in another post soon.

The focus of my talk was that the arrival of biometrics as a convenience technology in the authentication domain transforms the usefulness of this model in the mass market. There’s a world of difference between creating a new account at the dating site and then being asked to look at your phone (face biometrics are especially popular amongst older people, for example) and being asked to get out a dongle, insert your EMV card, enter your PIN, read a code and then type it into a web page. And, as an aside, one of the most interesting presentations I saw at the event was about he use of the phone and the touch screen to perform continuous background authentication so that when a service provider forces an authentication on the device, the customer may well have to do absolutely nothing at all!

One more thing about the model. On re-reading that chapter (which was first drafted a decade ago), I couldn’t help but notice that Neil and I had already had an inkling that the paths of the Internet of Things and digital identity would cross. We wrote:

People will account for only a fraction of the digital IDs associated with stuff, and a lot of stuff will be interacting with virtual identities: after all, a vending machine dispensing chocolate may not need to know anything about a person, but one dispensing cigarettes certainly does. Since it would be ludicrous (and an open invitation to identity theft) to insist that people present their real identity to a vending machine, it is the attribute (eg, “is_over_18” or something similar) bound into the virtual identity that is the critical element in enabling the transaction.

Rather forward thinking, if you ask me, especially since on my last trip to Frankfurt I discovered that there are cigarette vending machines in the street that require customers to present their actual identity cards (well, someone’s identity card, anyway) in order to purchase!

What the machine should do, of course, is require you to present your “adult identity” (that contains no identifying information and merely testifies that you are over 18) and then force an authentication against that (via Bluetooth or whatever). As we all know, in a commercial transaction of this nature, your “real” identity is your least important attribute.

Connecting is getting easier, disconnecting is getting harder

3rd December 2015by Consult HyperionLeave a comment

After I’d been blathering on at some event about how connecting things up is really but disconnecting them is really hard, someone sent me a link to a story illustrating an amusing case of the unexpected consequences of connectivity. A woman found out her husband was cheating on her with nanny because he had photos and texts on his iPhone, which was linked by iCloud to her iPad.

Gwen Stefani apparently discovered Gavin Rossdale was cheating on her after discovering some explicit texts and photos on the family’s iPad.
[From A guide on how to not let an Apple device ruin your marriage – NY Daily News]

I didn’t know who Gwen Stefani was, so I went off to goggle her on my skyper (as England’s greatest living poet, John Cooper Clarke, would put it) hoping that she might be a junior minister at the Home Office or an executive a technology company, but it turns out she’s a pop singer. Oh well. There’s no reason to expect pop stars to understand Apple’s settings any more than I do, so I put the story to one side. Until this morning, that is.

This morning I went through my browser history to try and find a page about a workshop that I was supposed to be going to. I couldn’t remember the name of the workshop, but I knew I’d been to the web site in the last day or two so I opened up my browser history. And found hundreds of web sites dealing with carpet remnants.

My wife and I are a very traditional couple. We share everything. It’s in our marriage vows. The bank account, the speeding tickets, the browser history. And we don’t have a nanny. So I don’t care about my wife seeing my browser history and she doesn’t care about me seeing hers. The reason I mention this episode though is to make a point: connecting things up is getting progressively easier, but working out who should be able to access what and when and under what circumstances is becoming increasingly complicated.

In fact, I’m tempted to say that it’s becoming so complicated that it will soon be beyond human comprehension. When I take a photo with my iPhone, I already have literally no idea where it will end up, and why some photos show up on my laptop and others don’t is completely baffling. (Although I have noticed that when I actually want to find a photo that I can remember taking a few months ago, I can never find it.)

Today it’s your photos, tomorrow it’s your financial transactions, soon it will be your identity that is unpredictably smeared through the interweb tubes with predictably chaotic results. Time for some thinking about identity partitioning and permissioning: more soon.