Security/identity · 2006-06-19


Pete Rowley’s thoughts on “people in the protocol” resonated with me, as they have with Paul Madsen; in fact, I had a great conversation with Pete about this general topic just after doing a user-centric identity panel at Burton Catalyst with Kim Cameron, Michael Graves, and Dick Hardt. But I think that to disambiguate all the options, we need a fuller set of terms, which indeed Paul lays out (this is the same set I used during my time on the panel).

The “user”-related terminology used in much of identity-land has been badly overloaded. One thing we’re all trying to do is articulate and label a philosophy (expressed in Kim’s “law #1” about control and consent, and brought up by Pam Dingle in the panel Q&A period) about building respect for users’ wishes into identity systems. Another thing we’re doing is discussing the pros and cons of specific protocol flows and user interfaces for achieving this. For starters, let’s not use the same term for both!

To recap the terms Paul lays out:

  • User consent is an umbrella term about giving the user the ability to consent (or not) to the exchange of their info. This is a minimum bar for respecting the user’s opinion about what should happen.

  • User control refers to a user’s ability to set policy that governs the exchange at a finer grain. This is a much stronger and subtler form of consent.

  • User centrism is reserved for a particular class of user-controlled identity info exchange wherein the technical protocol lets the user control the flow absolutely, by making them an intermediary at run time. (If we don’t reserve this term for this meaning, then a whole bunch of criticisms I’ve seen of “non-user-centric” systems make no sense!)

On the panel, I tried to point out a couple of things:

First, the Liberty Alliance is comfortable with the entire consent/control/centrism spectrum, and indeed it did some pioneering design work around identity clients that mediate information flow, which is now in SAML V2.0 as what’s called the Enhanced Client or Proxy — or ECP, pronounced “eck-pee”, sigh. (I even went so far as to assert that SAML and Liberty manage to have a single architecture for the entire spectrum of user empowerment choices, something I’ll try to elaborate on in a separate post.)

Second, some use cases lend themselves to user centrism, but some by their very nature take place when you’re not around — like medical professionals’ access to your health information when you’re lying insensible in the emergency room. (I didn’t know, when I brought this up, that there was a three-company demo in the Liberty suite that showed exactly this scenario!) Permission-based attribute sharing is at the very heart of Liberty Web Services.

One thing I brought up only later, to Pete and some other folks, is that we spend a lot of our time in the identity world trying to figure out how to securely remove synchronous (annoying, error-prone) user action from identity transactions — what is Single Sign-On about, after all? — and the last thing most users want is to be interrupted to handle some identity data flow when their predefined policy could take care of it for them. So I think there’s a bit of irony in calling the method that requires the most interrupting-of-the-user “user centrism” (centrality to the protocol is more like it, and more value-neutral). Or, since freedom and responsibility are twin values, we can see user centrism as the ultimate in user responsibility!

So, back around to philosophy… I like Pete’s “people in the protocol” phrase a lot, and think it would be great as the name of the overall philosophy we’re going for here. But reading his post again, I’m not sure if he means it to be applied to strict user centrism, or just to something like user consent/empowerment. When we chatted at lunch, I did ask whether it would be an acceptable model to gain user consent to an initial introduction between an identity provider and relying party, so as to let them “talk amongst themselves” thereafter in an approved manner, and he said yes. So perhaps we are indeed beginning to untangle the myriad ways of evincing respect for users.

UPDATE: Conor and I are having a discussion in the comments about finer gradations, terminological flexibility, and more that I’m finding very helpful. I wonder what others think: Is “user-centric” a term that’s here to stay, or open to further change as our understanding grows?