Lockstep

Mobile: +61 (0) 414 488 851
Email: swilson@lockstep.com.au

Identity is in the eye of the beholder

That is to say, identity is in the eye of the Relying Party.

The word "identity" seems increasingly problematic to me. It's full of contradictions. On the one hand, it's a popular view that online identity should be "user centric"; many commentators call for users to be given greater determination in how they are identified. People like the idea of "narrating" their own identities, and "bringing their own identity" to work. Yet it's not obvious how governments, banks, healthcare providers or employers for instance can grant people much meaningful say in how they are identified, for it is the Relying Party that bears most risk in the event identification goes wrong. These sorts of organisations impress their particular forms of identity upon us in order to formalise the relationship they have with us and manage our access to services.

The language of orthodox Federated Identity institutionalises the idea that identity is a good that is "provided" to us through a supply formal chain elaborated in architectures like the Open Identity Exchange (OIX). It might make sense in some low risk settings for individuals to exercise a choice of IdPs, for example choosing between Facebook or Twitter to log on to a social website, but users still don't have much influence on how the IdPs operate, nor on the decision made by Relying Parties about which IdPs they elect to recognise. Think about the choice we have of credit cards: you might for instance prefer to use Diners Club over MasterCard, but if you're shopping at a place that doesn't accept Diners, your "choice" is constrained. You cannot negotiate in real time to have the store accept your chosen instrument (instead your choice is to get yourself a MasterCard, or go to a different store).

I think the concept of "identity" is so fluid that we should probably stop using it. Or at least use it with much more precision.

I'd like you to consider that "Identity Providers" do not in fact provide identity. They really can't provide identity at all, but only attributes that are put together by Relying Parties in order to decide if a user or customer is legitimate. The act of identification is a core part of risk management. Identification means getting to know a Subject so as to make certain risks more manageable. And it's always done by a Relying Party.

An issued Digital Identity is the outcome of an identification process in which claims about a Subject are verified, to the satisfaction of the Relying Party. An "identity" is basically a handle by which the Subject is known. Recall that the Laws of Identity usefully defined a Digital Identity as a set of claims about the Digital Subject. And we all know that identity is highly context dependent; on its own, an identity like "Acct No. 12345678" means little or nothing without knowing the context as well.

This line of reasoning reminds me once again of the technology neutral, functional definition of "authentication" used by the APEC eSecurity Task Group over a decade ago: the means by which a receiver of an electronic transaction or message makes a decision to accept or reject that transaction or message. Wouldn't life be so much simpler if we stopped overloading some bits of authentication knowledge with the label "identity" and going to such lengths to differentiate other bits of knowledge as "attributes"? What we need online is better means for reliably conveying precise pieces of information about each other, relevant to the transaction at hand. That's all.

Carefully unpacking the language of identity management, we see that no Identity Provider ever actually "identifies" people. In realty, identification is always done by Relying Parties by pulling together what they need to know about a Subject for their own purposes. One IdP might say "This is Steve Wilson", another "This is Stephen Kevin Wilson", another "This is @Steve_Lockstep", another "This is Stephen Wilson, CEO of Lockstep" and yet another "This is Stephen Wilson at 100 Park Ave Jonestown Visa 4000 1234 5678 9012". My "identity" is different at every RP, each to their need.

See also An Algebra of Identity.

Remember the practical experience of IdPs. Despite a decade of hard work, there are still no Relying Parties accepting general purpose identities at LOA 3 or LOA 4. For high risk transactions, RPs like banks and government agencies still prefer to issue their own identities. Seamless operation of IdPs -- where an RP can accept an identity from an external IdP without checking any other authentication signals -- only works at LOA 0, where Identity Providers like Twitter and Facebook don't know who you really are, and the Relying Party doesn't care who you are. And at intermediate levels of risk, we sometimes see the crazy situation where RPs seek to negotiate LOA "one and a half" because they're not satisfied by the assurances provided by IdPs at vanilla LOA 1 and LOA 2. Customising identities makes a mockery of federation and creates new contractual silos.

So much of this complexity would melt away if we dropped down a level, federated concrete attributes instead of abstract "identities", re-cast IdPs as Attribute Providers, stopped trying to pigeonhole risk and identity, and left all RPs free to identify their users in their own unique contexts.

Posted in Language, Identity, Federated Identity

Comments

NatWed 13 Mar 2013, 4:39am

I agree that conflating authentication provider and identity (=set of attributes) provider is not good. We tend to use the word IdP to actually describe the authentication provider. We should stop it.

As to the definition of authentication, I like X.1252 definition better than APEC's. APEC's one is conflating it with authorization. Here is their definition: "A process used to achieve sufficient confidence in the binding
between the entity and the presented identity".

Stephen WilsonWed 13 Mar 2013, 6:17am

Nat, I think blending authentication and authorization is the best thing about the APEC definition! ;-)

The definition gets away from the arbitrary difference between "who someone is" and "what they are authorized to do". I think splitting hairs over authentication and authorization is unhelpful; the difference comes from engineering, not business. In most business transactions, authentication in context creates authorization. See http://lockstep.com.au/blog/2011/01/22/forget-authentication.

I'd like to get away from semantics. We should focus on what we need to know about someone to transact with them.

Post a comment

If you are a registered user, Please click here to Sign In

Your Name*

Your Email Address* required, but won't be displayed on this site

To help prevent spam in our blog comments, please type in "the" (without the quotation marks) below*