Links

Ben Laurie blathering


Why Identity Is Still Just Login

It seems everyone now agrees that Internet identity is about a collection of assertions relating to a person (or thing, if you want to go there). Some of these assertions are assertions one makes about oneself, for example “I like brussels sprouts”, and assertions others make about you, for instance “Ben is a UK citizen, signed the UK Government”. These assertions are essentially invariant, or slowly varying, for the most part. So what makes an identity, we agree, is some collection of these assertions.

But we also agree that people need to assert different identities: there’s Ben at work, Ben as a member of the OpenSSL team, Ben at home and so on. Each of these identities, we like to think, corresponds to a different collection of assertions.

All we need to do, we think, to map these identities onto collections of electronic assertions and we’ll have solved The Internet Identity Problem. People will no longer be required to type in their credit card number five times a day, endlessly write down their address (and correct it when it changes) and so on. The ‘net will become one lovely, seamless experience of auto-communicated factoids about me that are just right for every circumstance and I’ll never fill in a form again.

You can probably see where I’m going. The more I think about it, the more I realise that every situation is different. My “identity” is contextual, and different for each context. We know this from endless studies of human behaviour.

So, what was the point of doing what every electronic identity system wants me to do, namely aggregating various assertions about me into various identities, and then choosing the right identity to reveal? To match this to what I do in the real world, I will need a different identity for each context.

So, what was the point of even talking about identities? Why not simply talk about assertions, and find better ways for me to quickly make the assertions I want to make. Cut out the middleman and do away with the notion of identity.

In practice, of course, this is exactly what has happened. The only vestige of this electronic identity that makes any sense is the ability to log in as some particular “person”. After that all my decisions are entirely contextual, and “identity” doesn’t help me at all. And so what we see is that “identity” has simply become “login”. And will always be so.

In a sense this is exactly what my Belay research project is all about – allowing me to decide exactly what I reveal in each individual context. In Belay, the ability to log in to a particular site will become the same kind of thing as any other assertion – a fine-grained permission I can grant or not grant.

Note: I am not against bundles of assertions – for example, I think lines one and two of my address clearly belong together (though for some purposes the first half of my postcode, or just my country, should suffice) or, less facetiously, when I use my credit card I almost always need to send a bunch of other stuff along with the credit card number. What I doubt is that the notion of a bundle that corresponds to an “identity” is a useful one. This implies that UIs where you pick “an identity” are doomed to failure – some other approach is needed.

10 Comments »

  1. I don’t think so, Ben. You’ve simply substituted “context” for “identity,” but the principle remains the same. In any given situation (that is, “context”) the identifiers, or attributes, are relatively constant. Entering that context (the office, your home, a particular web site, etc.) there’s a certain collection of attributes/assertions you want to bring along: in short, an identity for that context. That’s what we’re all trying to make easier – and changing the nouns doesn’t particularly help.

    -dave

    Comment by David Kearns — 27 Nov 2010 @ 15:46

  2. You appear to be agreeing with me: there is a different “identity” for each context.

    Right now, most efforts seem to be focused around collecting attributes into one or more “identities” which are then used in multiple contexts. I am claiming that there is no such re-use in practice and so the focus on collecting attributes into identities which you then use in contexts is not useful.

    Instead we should figure out how to use attributes in contexts easily, missing out the “collect into an identity” step.

    This seems important to me because grouping attributes into a collection remains hard. If we continue to entertain the idea that identities are reusable then we can continue to avoid the question of making grouping easy, justifying this by claiming it is a relatively rare event.

    Comment by Ben — 27 Nov 2010 @ 16:58

  3. Ben,

    I suspect that you might be being deliberately provocative here, so I won’t leap snarling right onto the bait.

    You touch upon many important points – persona (the ability to present different faces to the world), personalisation (the ability for services to adapt to the individual using them) and context (the realisation that interactions aren’t uniform).

    Identity is clearly more than login, but the web is old enough and ugly enough for us to have seen many attempts at getting much beyond login fail. Perhaps the most glorious failure was information card. It did a great job of hiding the complexities of PKI from a user; it recognised the importance of context – presenting the user with a wallet metaphor – a different card for a different purpose, and it had a consistent user ceremony. From where I’m sat it only failed because its main proponent (Microsoft) was utterly hopeless in marketing (what may have been one of the few none lame things about Vista) [though there is the glaring issue that no service provider, including MS's own Live, ever bothered to support it - despite some of the right noises being made in the early days]. I think you’re previously linked to efforts that looked like information card with a pure browser selector, and my fingers are still crossed that such things will become usable and gain popularity.

    I don’t want identity to be just login. I want my machine, and the machines it talks to to be able to deal with me as seamlessly as possible.

    Furthermore I want a single login to be contextually reused across different facets of a service provider (a concept I’ve previously labelled an ‘anchor identity‘). Is this asking for too much?

    Comment by Chris Swan — 27 Nov 2010 @ 17:38

  4. Dave — putting words in Ben’s mouth (and he can correct me if I’m confused here), it reads like he’s saying that attempting to create identities which are suitable to every context results in one of two cases.

    In one case, you tailor the attributes provided in any given context so specifically that the result of doing so is functionally the creation of separate identities for each and every context. Needless to say, this rapidly becomes an unmanageable proposition.

    In the other, you create identities which are generic enough to be able to apply across multiple contexts, which either results in exposing more attributes than desired, or a need to continually supply the missing attributes for whatever context you happen to be in.

    If, instead, you move the grouping of attributes to a ‘lower’ level, than it’s easier to control which attribute or set of attributes you chose to expose in any given context.

    Instead of having something like your ‘Home’ identity, that you use for online shopping, dealing with the government, and your kids school, eg:

    Home Identity: Name + Address + Birthdate + Credit Card + Passport Number

    You’d have something more like sets of attributes which are exposed according to context, eg:

    Attr_NAME: (Name + Address)
    Attr_GOV: (Birthdate + Passport Number)
    Attr_Credit: (Credit Card)

    A ‘Government’ context may have access to: Attr_NAME, Attr_GOV
    A ‘School’ context may have access to: Attr_NAME
    An ‘Online Shopping’ context may have access to: Attr_NAME, Attr_Credit

    You might even group your sets, to end up with something like:

    Attr_Shopping: Attr_NAME + Attr_Credit

    An ‘Online Shopping’ context may have access to: Attr_Shopping

    Comment by cat — 27 Nov 2010 @ 18:19

  5. Whether the attributes are collected within each context, or at a central point for delivery to a context doesn’t seem to be much of a difference. And, of course, many of those attributes are used in multiple contexts (last name, for example) so storying them centrally makes maintenance that much simpler, you reckon?

    Comment by David Kearns — 27 Nov 2010 @ 21:02

  6. There’s a difference between storing them centrally as one huge immutable lump, and storing them centrally as discrete objects that can be selected as appropriate.

    Comment by cat — 28 Nov 2010 @ 18:25

  7. Ben,
    If I didn’t know better, I’d think you had been attending our recent Jericho Forum workshop meeting!
    We’ve been looking at de-identification – removing “identity” (whatever you mean by that) where it’s not needed.

    Some details of the approach were published a while ago in http://www.opengroup.org/jericho/COA_IdM.pdf. In particular:

    In most cases, data attributes should be held by the end user, rather than centrally stored by a
    third party. For browser-based applications, a standardised data form schema would make it
    simple to pass the same data to different organisations completely under user control.
    Individuals should be able to choose which sets of attributes are used for a given transaction
    (work/home address, credit card selection). (JFC#8)

    In other words, browser form-filling options under user control meet most, if not all, of the requirements.
    Not that I think it’s going to be easy to retrospectively get agreement on naming sets of attributes (or claims). But the same standard naming problem hits alternatives such as InfoCards – and they additionally require software at the server, making them even harder to adopt.

    Any takers to define global standards for the field names (and sizes and content) for common groups such as name-and-address, payment card details, passport details?

    Comment by Andrew Yeomans — 28 Nov 2010 @ 22:44

  8. Paul Madsen and I had an interesting IIW session last year where we observed that in human interactions, identity information is almost always revealed gradually. E.g. visual, then first name, then where are you from, common acquaintances, employer… Often that process continues over so many meetings, perhaps over months.

    Handing over the equivalent of an “identity” (as a package) or even a “persona” right up-front is very unnatural and would not meet the requirements of social interaction. I postulate that any “identity technology” that is not really good at supporting this gradual revelation process will not be useful. So in other words, I agree with you.

    Comment by Johannes Ernst — 29 Nov 2010 @ 0:31

  9. @Andrew Yeomans: Info Cards started to extend the 14 CardSpace claims schema to include abstract claims such as ‘over 21′. POCO (Portable Contacts schema) see: http://portablecontacts.net/draft-spec.html has seen commercial interest recently. These do not touch the payment card claims/fields or government-assigned unique values (SSN, Passport, driver’s license). But there are PCI-DSS standards for EFTs between credit/debit and businesses. MyDex started with 2500 data types describing everything from birth to death.

    Regardless of the encryption mechanism, the claim wielding ceremony, whether the IdP is active/passive, self-asserted claims, cross-silo or silo-specific details, there should be an international standard for describing the claim/fields so that context-specific tools of various types can work together. Common structured data types are where we should put a stake in the ground.

    Comment by Charles Andres — 10 Dec 2010 @ 17:04

  10. Why are people talking about attributes? The word “attribute” does not appear in what Ben wrote. He did use the word “assertion” a lot. There’s a difference. For example,
    the assertion “I am am old enough to view pornography, so sayeth …” is a lot more, differs from, and cannot be captured by, an age or date of birth attribute.

    Assertions are statements about compliance with rules. So perhaps we should be talking about rules instead of attributes.

    Comment by Eric Norman — 10 Dec 2010 @ 18:04

RSS feed for comments on this post. TrackBack URI

Leave a comment

Powered by WordPress

Close
E-mail It