Here's a radical thought: why don't we Internet engineers forget about identity?
Businesses and individuals identify each other in various ways and to different ends, but always basically in order to manage the risk of dealing with the wrong entity. By and large, we actually do identification pretty well. There are many mature analytical methods and standards by which identification can be analysed and designed, as just one element of risk management.
One of the difficulties in Federated Identity is that it too often pressures participants to change the way they do identification. Now there's nothing wrong with change, and I'm not saying that identity management practices are perfect by any means. But they're changing already. They always have and they always will. What I am saying is that global identification is never going to happen, and neither will global identification benchmarks, like Levels of Assurance. We can think globally all we like but risk management requires fundamentally that businesses will always act locally.
Identification practices undergo continuous improvement under circumstances peculiar to different businesses, industries and jurisdictions. Most industries at some level constantly monitor the adequacy of identification in the face of fraud trends, and make steady adjustments. Some identification protocols are legislated, as in the 100 point check of the Australian Financial Transaction Reports Act and anti-money laundering laws. Some protocols are set by industry overseers; for instance, doctor credentialing is regulated by local and state health agencies with a degree of national coordination. Ad hoc standards (more like habits really) emerge all the time, such as the way so many hotels have taken to photocopying driver licenses at check in. For the most part, identification rules are made up by industry bodies and by businesses themselves to suit their local risk profiles. In general there are no laws that prescribe how employers identify their staff, nor universities their students, nor professional bodies their members -- just as there is no national identity card here.
In going online, several widespread problems in identification have arisen. We all know what the problems are: the inconvenience and cost of repeated registrations; the overhead of managing multiple accounts and often inconsistent authentication mechanisms (multiple passwords, and separately, the "token necklace"); the privacy risks that go with redundant registration information flows and records; identity fraud and "identity theft". These problems are mostly separable and are amenable to improvement without imposing global identity management practices, let alone re-engineering identity itself.
The process of identification boils down to presenting certain pieces of claimed information about the person or entity, and validating those claims. In improving identification in the digital environment, we must focus with more precision on the real problems needing to be solved. And we must avoid wherever possible imposing changes from outside on the way that businesses choose to know their customers, members, staff, partners and users.
Around the world, governments and public-private partnerships continue to strive for big over-arching "Identity Frameworks". I think we need to heed the lesson that Federated Identity is easier said than done. Really worthwhile efforts have repeatedly failed, none more significantly than Microsoft's flagship identity solution Cardspace. I'm positive the underlying problem is simply that identity is not what it seems. Digital Identity is metaphorical; it's not a real thing at all but instead is a proxy for a relationship. And we know that relationships are difficult to carry over across different contexts.
So what's to be done? In my view, a subtle but significant course correction is due. Why don't we drop down a level, forget about "identities", and put our energies into making reliable information about claims more widely available? Fortunately, all the orthodox identity frameworks include Attribute Provision, and let's remember that the Laws of Identity themselves teach that Digital Identities are "sets of claims made by one digital subject about itself or another digital subject". I've discussed elsewhere that the interoperability of IdPs and RPs is more complicated than simply matching Assurance Levels, because it's the details of the elemental claims that really matter. So why don't we stop trying to centrally govern how identities are defined by Subjects and by Relying Parties, and focus instead on improving the mechanisms for conveying the more atomic claims that power those identities?
The diagram shows how a marketplace of verification services could grow around a set of commonplace claims.
NB: "DVS" stands for Document Verification Service, currently operated by the Australian Attorney Generals Department, which allows state & federal government agencies here to inquire as to the validity and currency of a range of identity documents.
The approach includes many of the standard privacy and security features of higher order Federated Identity systems, such as information hiding APIs delivering only 'yes'/'no' answers to claims queries. But the approach stops short of describing any "identities" per se or characterising "assurance levels" and the like, leaving Relying Parties to continue to set their own identification rules, and to realise those rules by shopping around for claims verifiers that suit their purposes.
To help RPs make up their own minds about the veracity of each attribute in this marketplace, the Yes/No answers from each Claim Verifier (aka Attrinute Authority) would be digitally signed by the verifier. The certificates used to validate the signatures would chain into a root CA for the whole scheme; every verifier in the scheme would be certified and regulalry audited, with their status reflected in their certificate. This sort of PKI means that the signed Yes/No answers can be seen to have originated from legitimate organisations, andorsed by the scheme. That is, there is clear provenance of the claims, the organisations that issued them, and the manner in which the claims were conveyed to the RP.
The Yes/No answers could be delivered on demand, in real time, or (as is my preference) the answers could be baked into end user certificates issued to convenient personel devices like phones or smartcards, and then presented directly by the user, for better privacy and control.
The suggested system has the following qualities:
- It does not impose any identification protocols on businesses, who remain free to select which claims and combinations of claims they want Subjects to exhibit.
- It does not change the context in which businesses deal with their customers/members/staff/partners/users.
- It is contestable. While there will be natural authorities (or 'sources of truth') for many claims like driver license numbers or date of birth, the proposal allows for other organisations to offer claims validation. Secondary data sets can be just as reliable (or even more so) for claims such as street address, alternate names etc. Information brokers can be expected to value-add certain claims, attest to baskets of claims, and/or bundle claims validation with other business services.
- It is much easier to ascribe liability around the validation of precise claims than the validation of "identity"; this approach should be more palatable to banks, government agencies and so on than other Federated Identity concepts where IdPs are asked to underwrite 'who someone is'.
- It is pragmatic; it avoids semantic technicalities like the difference between "authentication" and "authorization"; the proposal simply provides uniform market-based mechanisms for parties to assert and test elemental claims as a precursor to doing business.
In closing, I'd like to quote Dazza Greenwood on identity:
"Former Speaker of the House Tip O’Neil used to say that all politics is local. Similarly, it can be said that all identity is local as well. Not necessarily geographically local. A parent can have children across the country and a bank for example can have account holders all over the globe. But they are "logically local" in the sense that they are all "home grown" and make sense largely only in their internal context. The account number by which each banking user is primarily known and the attributes surrounding that number are not similar to the naming and identity scheme required by medical clinical systems, for example. One size does not fit all because the subtle contours and content of identity is not monolithic." Ref: Authentication and Identity Management: Information Age Policy Considerations, Greenwood, 2003.
Indeed: identity is not monolithic. We might make much better progress on the digital identity challenges if we dropped down a level and tried dealing with identity's common parts instead.
I hope the technology behind ID verification advances so that access can be TRULY organized... :)
This is similar to the message that I have been banging on about for over 10 years, first expounded to me by Ron Rivest in the 1990s when he was working on SPKI/SDSI. Services dont want to know who you are, they want to know what you are authorised to access. With research funding we have built a prototype system that does precisely that. For example, it allows a user to buy a car parking permit on line, by providing claims that
i) he owns a car (claim from the driving authority)
ii) he lives in the locality (claim from the pension authority)
iii) he can pay for it (claim from a bank)
You can run the demo from here.
Currently it only works with firefox browsers and you have to install the plug in we provide to run it, but it shows the way we are thinking and what can be achieved.
Steve, love the concept, especially about moving away from a single identity and making everything attribute-based.
where would these claims be stored, on the user's mobile device? If so, what if the mobile device's battery dies, is lost/stolen, etc.? What if the user tries accessing a site from a different device?
How would you envision the user managing these claims, an app of some kind? If an app, what kind of app and provided by whom?
If the claims are on the mobile device and the user is trying to access a website from a PC, how would the merchant/organization request claims from the user?
Must each of these verification services maintain a live/working verification API? Wouldn't they then be verifying the same attributes repeatedly, in addition to maintaining the API? Why not have the verifier sign an attestation of each attribute and put it where RP's can read it when they want it?
Sorry if these answers should be obvious, I'm just trying to understand the mechanics of your proposal and how it compares to what we're building.
By and large, yes, users would copies of verified attributes (each one being a digital certificate signed by the attribute authority) on their mobile phones, or other devices (smartcards, wearables, USB keys etc.). Of course this creates some dependency on those devices, but we safeguard our phones and wallets anyway. It's good for hum behavious, and good for security, to have what I call *proper* two factor authentication: if you lose the hardware factor, you have to get a new one. I note that the FIDO Alliance is now tackling some of the real world issues here.
The APIs needed for this vision are very basic and are mostly in place already in crypto API libraries. The primitives are (a) create a new certificate containing an attribute, (b) sign a data object using a particular certificate, and (c) verify a digital signature against a certificate. Certificates would be indexed by Policy OID - each app looking to handle attributes in this way would know about Policy OIDs and the ones that are relevant to the domain, eg professional qualifications, personal biographic attributes, financial data etc etc.
Forgive the PKI dirty talk; a Policy OID is a pointer baked into a certificate that, if you need to find out, takes you to a comprehensive specification of the certificate's semantics, business rules etc. Each attribute authority would stamp its certificates with a particular Policy OID, At design time, developers need to work out which OIDs correspond to authorities that are reliable in the application domain; at run time, all the software needs to do is check that the presented certiticate contains a resignised OID.
As to why you wouldn't sign an attestation and store it where RPs can see it, sure, but then the problem is when a stranger rocks up and says 'Hey, look over there at the signed attribute [on a public regsiter or blockchain etc.]: that's me' then the RP has to determine if the stranger goes with the attribute. You usually do that with a cryptographic challenge-response, backed up by knowledge that the stranger's key is correct.
If you have to have end users with private keys (and ask anyone who's fried a BTC wallet and they'll tell you) then I say it's much more elegent to bind those keys to attribute certificates that convey the exact information you're interested in.