If you work in e-commerce and cyber security policy, law, regulations or strategy, you've almost certainly been taught the difference between "authentication" and "authorisation". One describes 'who you are' and the other what you're allowed to do. The dichotomy is at the heart of most network access control, and it informs almost all contemporary thinking about digital identity. And it's misguided.
I believe the sterile language of authentication and authorisation, especially the orthodox primacy of the former over the latter, has distorted the study of digital identity. By making authentication come first, the language cements the tacit assumption that we each have just one main identity, and it surfaces that core identity in all routine transactions. This is not a good starting point if we seek the right balance of security and privacy online.
Kim Cameron tried to shift this dichotomy with his "Laws of Identity" but sadly this particular subtlty never quite caught on. Cameron said that digital identity is "a set of claims made by one digital subject about itself or another digital subject". This means that a digital identity is really all about the attributes, breaking the nexus between authentication and authorization. Cameron recognised explicitly that this new view "does not jive with some widely held beliefs – for example, that within a given context, identities have to be unique". And that belief is indeed widespread: it's at the heart of the "nymwars" dispute that erupted over Google's and Facebook's Real Names policies. Unfortunately, for all the forcefullness of the "Laws", opinions about the number of identities we 'really' have remain polarised.
People have been confused about the 'real' identity versus digital for a long time. A dogmatic obsession with 'real' identity is what shoved PKI off the rails in the mid 1990s. There are purists who say PKI can only be concerned with identity, but we really need to move away from an absolutist view of authentication.
In the vast majority of routine transactions, parties are only interested in authorisation and not identity. Consider: pharmacists dispensing prescriptions don't "know" (let alone trust) doctors. Investors don't "know" a company's auditors. Airline passengers don't "know" the pilots nor the airframe safety inspectors. Bank customers don't "know" their tellers. Employees don't "know" who signs their pay cheques. The parties to these transactions may be mutual strangers and yet they obviously know enough about one another to be able to transact usefully. Each party has a dependable identity in a particular context. In context, they are not total strangers. We can conclude that identity-in-context is precisely the same thing as authorisation.
The idea that authentication and authorisation are different things is an artefact which, it seems to me, arose when 1970s era computer scientists started thinking about resource access control. The distinction does not usually arise in regular real world business, where all that matters in routine transactions is the credentials of the sender, in context.
Internet commerce is a collision of worlds: IT and business. And far too many of the default assumptions, language and sheer imaginings of technologists (like "non repudiation") have infiltrated our e-business paradigm. It's ironic because we're told incessantly that e-business and identity management are "not technology issues" and yet the received wisdom of digital identity has come from computer scientists!
In IT, "attributes" and authorisation are always secondary to identification and authentication. Yet the real world is subtly different. Yes, I identify myself with a primary authenticator like a drivers licence when I open a new bank account or join a video store. However, I never use that breeder ID again, for the bank and video store each provide me with new credentials; that is, new identities in their respective contexts.
Surely the authentication-authorisation split is unhelpful to the twin causes of Internet security and privacy. It exposes to theft more breeder identity information than is generally necessary, and it enables otherwise dispirate business to be joined up. The sooner we cement a new simplifying assumption the better: in most routine transactions, authorisation and not identity is all that matters.
Better clarity follows about what the real problem is with digital identity. For the most part, our important business attributes (and the ones that are most prone to ID, like account numbers, social security numbers and government identifiers) are grounded in conventional real world rules. They are issued by bricks-and-mortar institutions, and used online. The main problem is not with existing identity issuance processes; it's with the way perfectly good identities once issued are so vulnerable online. We usually present our ids as simple alphanumeric data, which are passed around through the matrix without any checks on their pedigree. So the real challenge is to preserve the integrity, authenticity and pedigree of the different identities we already have when we exercise them online. This is actually a straightforward technical issue, with readily available solutions using ordinary asymmetric cryptography. It is not at all necessary to engineer a whole new identity paradigm, changing the time-honored conventions by which meaningful context-specific identities are issued. We simply need to take the recognised identities we already have and convey them in a smarter way online.
Steve, excellent post per usual. Completely agree about the fact that attributes matter and that even these get confused between those used for authentication and those for authorization. As you probably know we are kicking this around in Kantara Attribute Management Discussion Group here http://kantarainitiative.org/confluence/display/AMDG/Home
I agree with the problem as I understand that you have presented it - authorization and authentication have become muddled by, in my opinion, IT driving solutions rather than business. In my opinion, a subject needs to be authorized in order to conduct business transactions and that authorization MAY include authentication. I am not a fan of the way things seem to be done today - authenticate someone and then authorize them to do something.
I believe that you are correct in your statement that, in most real world transactions, the service provider just wants to do something to authorize you to receive the service they are offering - either a payment guarantee (credit card, cash, etc) or some proof that you meet some specific requirement (age greater than 18). In my opinion, the vast majority of transactions DO NOT require identity authentication and a larger (but still small) number require some attribute authentication.