Lockstep

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

An Authentication Claims Exchange Bus

Last week I had the very great pleasure of participating in the first MIT Legal Hackathon, organised by Dazza Greenwood and Thomas Hardjono for the MIT Media Lab, Kerberos Consortium and wwPass. I say first because they plan to hold a monthly hangout! I hope and expect that this will become a strong, dynamic new forum for multi-disciplined explorations of Digital Identity.

In Dazza's wrap-up of the event, he pondered the potential for "open public infrastructure for identity":

... like a big bus of some sort for essential claims from public or other sources, utilised foundationally for identity functions."

His idea builds out logically from a proposed system of claims verification services that I presented to the hackathon, and blogged about a few weeks ago. So for discussion, here's a further development of the schematic. A variety claims verification services would be made available over a common bus as Dazza suggested, and used by a Relying Party to assemble the particular fractions of information they decide will make up a Subject's identity in a given transaction context.

Lockstep Identity Claims Bus after Dazza Greenwood 130203

Something I really I like about this architecture is that it supports several different modes of identification. For one, it could be used in real time by an RP faced with a fresh user for the first time; the RP could in real time seek out 'attribute providers' in the OIX or Identity Metasystem way of working. Alternatively, for well-worn e-commerce transactions where the necessary claims are well known in advance, the Subject could put together a basket of claims in advance and carry them in an identity wallet to be presented directly to the RP.

The diagram also shows a visualisation of the claims of interest to the RP for the transaction at hand, and the necessary degree of confidence i each of them (i.e. 90% in name, residential address and date of birth). I discussed this way of looking at different claims sets as surfaces in another blog last year.

As we rethink identity orthodoxies in forums like the MIT Legal Hackathon, I propose we shift perspectives a little. For instance:


  • We should drop down a level, and focus on ways to exchange information about elements of identity, rather than rolled-up "identities" themselves; that is, we should fractionate identity into its important component parts, guided by transaction context.

  • When building identification services frameworks, we should avoid imposing particular business protocols on organisations, so they remain free to select which claims and combinations of claims they want Subjects to exhibit.

  • We can avoid technicalities like the difference between "authentication" and "authorization", and indeed we can remove ourselves from the philosophical debates over "identity"; the proposal simply provides uniform market-based mechanisms for parties to assert and test elemental claims as a precursor to doing business.

  • Life looks much simpler under the neutral definition of "authentication" adopted 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.

None of this is actually radical. We've always thought about claims and attributes, all the authentication protocols deal with attributes, the good old Laws of Identity were actually all about claims, and there is infrastructure to deal with claims.

I think we just need to shift focus. We technologists shouldn't be so preoccupied with identity per se; let businesses continue to sort out identities as they see fit, and just give them the means to deal digitally with component claims. Let's not put IdPs ahead of APs. It may turn out we don't need IdPs at all. It's all about the claims, and only about the claims.

Comments welcome!

Posted in Identity, Federated Identity

Comments

Adrian SladeWed 6 Feb 2013, 1:31am

Hi,

I think other organisations share this very same concept of Mr. Greenwoods.

The UK government Identity Assurance (IDA) programme is partially down this road, I believe several private organisations contributed to the designs, and the UK govt took a 'big' steer from the OIX group.

The UK Gov are starting out from a Citizen prospective and intend that multiple government silos act as 'attribute providers' (including DVLA). The UK post office are offering a idP service catalogue, primarily registration and verification services - Face to Face ETC but also have a pitched their own idP service.

After the Citizen based, intiative it is hoped that a market in idP services would develop, but who pays who for what is the problem!

In a market based idP world do agregators and service providers get a minimum claim by default and have to offer icentives for more?

Does a commercial idP service provider charge a consumer for secure managment of online ID e.g. Bank idP levvies % of online transactions...

Does the insurance industry have a hand to play, offering reduced premiums to users and business that use commercial idP services.

Ade

Jim FentonThu 7 Feb 2013, 10:12am

Steve,

I don't really like the characterization of a "bus" here: it tends to imply that data is flowing freely between the different entities on the bus, and (I hope) that's not the case here. Instead, I'd rather include the IdP (which should be representing the user, and trusted by him/her) here. The IdP can assist in locating sources of claims that would be trusted by the RP, and can also assert the user's authorization to the attribute providers to permit them to release the attribute information.

I think it's important to recognize the need for an agent acting on behalf of the user (the IdP) and that attribute providers may represent the user or not depending on the type of attribute being dealt with.

Stephen WilsonFri 8 Feb 2013, 7:17am

Thanks Jim.
I'm dubious about the general cost and complexity of intermediating RPs and the sources of truth they use to authenticate users. When you mention 'locating sources of claims that would be trusted by the RP' what do you have in mind?
Isn't it almost always the case that the natural source of truth for claims is obvious, or very limited? See the sorts of verifiers in my diagram vouching for the sorts of claims at the right.
I can definitely see intermediaries evolving over time, similar to how business information brokers like D&B have set up shop intermediating companies and definitive corporate databases. These brokers actually charge money for extracts from databases that are freely available to the public, offering various value adds. I think the same thing will happen with identity information. But evolution will be bottom up. Designing and building artificial ecosystems around preconceived notions about how novel intermediary "Identity Providers" should work seems fraught with crystal ball problems.

Jim FentonFri 8 Feb 2013, 10:58am

Steve,

I see some privacy issues with eliminating the intermediary. In particular, in the model you show, DMV gets to see what RPs are asking for the user's age or address. There are situations and users that would object to that.

I don't have in mind a D&B type of intermediary, though. Once the identity ecosystem gets built out, the user might have several sources for, say, an assertion that he/she is over 21. The multiple sources might have different levels of trust, might be in different domains (e.g., healthcare vs. banking), and there might be different costs associated with obtaining an assertion from each. Some sort of negotiation might be needed to determine which one to use, and I see the user's agent as intermediating this. In addition, it might not be obvious where to get some assertions: which DMV do you query? There are corner cases where the user's mailing address might not give the right answer.

I described some of this in a presentation I gave a few years ago, which is at http://www.slideshare.net/jim_fenton/identity-systems-8537393 , slides 20-23.

Stephen WilsonFri 8 Feb 2013, 11:21am

Jim, I agree completely the identity of the RP should usually be hidden. We ca do that at the API level on the client side can't we? And to your earlier point, indeed, not everyone on the bus should see all the traffic. Maybe bus is a weak or distracting pattern. So we probably agree on most matters ... except ... I have a using intermediaries for protecting privacy because that only pushes the promise-not-to-tell from one place to another. I'm more comfortable myself with established RPs making that kinda promise than new start-ups operating under new business models and breaking new regulatory ground as they are in federated ID.
Cheers, Steve.

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 "An" (without the quotation marks) below*