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?
I’m all on the same page with you Eve on everything but the term “user centrism” as I fear that this is one of those “feel-good, but don’t understand the implications of” terms that will be heavily used in marketing to push one mode of communications over another.
The current use of the term as you’ve outlined it will be interpreted by many to be that my client running on my local device (such as a PC) must be the entity in the middle doing things on my behalf (as the user themselves usually does not talk computer protocols to other computing entities). I would stipulate this is no better from a security/trust point of view, and perhaps worse, than the user having a trusted on-line entity that does the same for them.
In both cases the user is trusting a piece of software (that they select) to intermediate on their behalf in identity related transactions. In one case it’s running on their own systems which we all know are quite susceptable to hacking of one form or another and in the other case it’s running on someone elses system who, one would hope, would have a reasonable IT department with reasonable IT policies and procedures to protect accesss to the systems at hand. Of course, these network guys would be a more target-rich environment (if they are cracked you get to lots of users vs if I crack a PC I typicaly only get to one user’s data).
So, to summarize, I think that we should not imply that user centrism means that the data flow goes through my local device and it definately does not flow through the user (at least no users that I know of).
Conor
(Conor, dude, you really need a blog… :-) ) I agree with you that everyone — including me, in the above post, for shame! — tends to conflate the human with the client software/device that represents them on the network and in a protocol. And I absolutely agree that the security risk profile of the user’s selection of, and usage patterns with, such a client is not necessarily better than a different model, not least because of the many deployment options and considerations.
However, unless we start distinguishing the case of identity data flowing through the user’s client (there, I said it) on their say-so in real time from other principal-directed actions (and from actions that are not principal-directed at all!), we can’t even talk sensibly about the options or compare them. So, given that the industry is beginning to consistently label this particular flow “user centrism” (this is certainly how Mike Neuenschwander and Jamie Lewis of Burton Group were defining it at Catalyst), I’d rather spend my energy ensuring we at least have names for all the important concepts, not just one. (Though as I noted above, “user centrality” — or maybe it should be “client centrality”! — would be more value-neutral and not imply some inherent magical goodness that no other use case has.)
I think there’s potentially great value in the sorts of UIs that are currently being discussed for the, uh, client-central approach. Microsoft, of course, has a lot of experience and talent at this sort of thing. And Sun’s Liberty on the Desktop demo (link is to a slightly older one than was shown last week — Hubert, let us know if you post the new one) using signed applets to manage the “card” selection process has been getting a hugely positive reaction from customers. But here’s a subtlety you can’t get to if you don’t have enough words: The same UIs would be useful for helping users set policy for future direct interactions between their identity providers and service providers — in a user-controlled model.
Yeah.. I do need to get a blog… and plan to do on one day… However, in the meantime…
I still think that there’s something that we’re ignoring that’s in between the user-controlled and user-centrism models (or a breakdown of user-centrisim into two implementations: the local client model and the network model.
In other words, I still see a model for a trusted network provider who sits between my Identity providers and my identity consumers on each transaction and, under my consent — either direct or by policy, controls the flow. This would still be in the user-centrism model (IMHO) although it is not physically located on my local client platform.
Conor
Ah, I see now, so we need an even finer gradation in terms. Maybe user client-centric vs. user proxy-centric??
Or, perhaps, local user-centric and remote-user-centric.
I do still have problems with the term centric or centrism as makes it seem like the others aren’t and will be used in marketing and lobbying that way (we have already seen some stuff mis-labled as non-user-centric).
Perhaps something along the lines of User-in-the-middle or user-intermediary. None of them sound as “good” from a marketing point of view as centric, but they are more appropriate because I fear that the feel-goodness of the term user-centric will drive people there without understanding what it means and will be used negatively against the other models which also have good potentials .
Remember that today some people do keep their money in between their mattresses and pay for everything by cash, but the majority of us use a bank and/or credit card and pay with cash replacements which the issuer can use to see where we spend money — but that’s ok since we trust them to not do bad things with that information.
Conor
I’d love to learn that people are open to changing the terminology. It’s only recently that we’ve gotten enough clarity about what some people mean by “user-centric” to even have this conversation. But I guess I’m a bit pessimistic about the likelihood… At least now we have a spectrum to choose from: :-)
user-centric (rainbows and kittens)
client-central, user (or client)-intermediary (objective, dry)
user-in-the-middle (vaguely sinister)
I do find it a bit strange that identity selectors on client devices are being touted as the ultimate in user-friendly goodness, to the point where sometimes the alternative is being treated as anathema. If there are good reasons to do things through a client for privacy or scalability or security in various circumstances, great. But hopefully no one is making an argument that it’s inherently more convenient. Heck, I arrange to pay as many of my bills as possible automatically, without my being online or physically present — otherwise I’d only forget, or be annoyed when reminded.
When I read stuff that’s happening in the identity world, I can’t help but thing there’s massive overlap with/reinvention of the P3P work.
While it’s common to perceive P3P as inflexible and not widely deployed, it is supported by something like 30% of commercial Web sites, and things like APPEL and EPAL do address a lot of the scenarios you’re talking about.
Has anybody looked into this?
Hi Mark– My guess is that the people doing identity systems would very much like to avoid reinventing the wheel when it comes to policy expressions, including privacy policy! It’s not overlap, maybe, so much as complementary goals. The identity systems would function ultimately as policy enforcement points, but would want to use specialist technology for policy decision points.
I haven’t heard much (or anything, to be honest) about APPEL or EPAL lately. However, it’s interesting that P3P is used in so many cases; I hadn’t known. I’ve heard, indeed, that it’s static and inflexible and thus impractical for many common scenarios but have no personal experience with it.
Another technology that leaps to mind, particularly where fine policy granularity and the full gamut of access control options are requirements, would be XACML. It even has a privacy profile already.
I always turn to my expert colleague Anne Anderson for thoughts on such things. I’ll ask if she’s interested in commenting further here.
Hi guys,
it sounds to me that Connor is describing something customer-facing (the user does need to be present and validate the process) and agent-facing (there is a proxy or agent that has the user’s authority to approve the exchange of info); am I guessing right?
BTW, yes I do need to create a new flash version of our demo; soon…
Cheers,
Hubert
I’ve tried floating the notion of ‘user sensitive’ identity…
http://blogs.sun.com/roller/page/racingsnake?entry=user_sensitive_identity_management
And Richard Veryard (whose opinion I rate) suggested that is too ‘weak’, and proposed ‘user responsive’.
I think one of the issues with ‘user-centric’ is the strong ‘spatial’ or topological analogy which it implies. As Conor points out, that drags in assumptions of ‘all traffic passing via the user’, which is by no means what is always functionally required.
Hi Robin– But all traffic passing via the user(‘s client) is precisely what a lot of people are proposing, and they call it “user-centric identity”. My take on Conor’s suggestion is that if the salient feature you want is the decoupling of the IdP and RP, then you don’t strictly need a “local” (client-based) intermediary to make this happen; a “remote” intermediary working on your behalf would suffice as well. Even though I’m doubtful people will step back from the “user-centric” terminology, it’s clear we at least need finer-grained terms than we’ve got.
For an umbrella term, I think there are a number of choices (none of which should be “user-centric”!): empowered, governed, responsive, and even sensitive… “User-consented” isn’t right for the name of the philosophy; it speaks only to a raw property of exchange, and doesn’t convey the idea that human-computer interaction principles matter.
I don’t believe that our life is so complex so as to need such myriad of terms (user client-centric vs. user proxy-centric and so on). On the contrary, I think that we should strive for simplicity: “user-centric” is the new marketing buzz word and people seem to like it, however in my opinion it shouldn’t imply that the user (and/or the user terminal) needs to be in the middle of every transaction. As Eve mentioned, I can definitely control what my bank does with my money, and I certainly do not need to be consulted for every single Euro that leaves my account, or be physically involved every time that a payment order reaches my bank. This doesn’t mean that my money is less safe (or at least by now ;-)
I also agree with Conor: the user can have the full control of his online data and/or resources simply because of the existence of marvellous “remote control tools”, namely “user-defined policies” that govern the way in which his information is accessed/shared.
And such policies could be enforced by the user terminal, by any sort or Hw/Sw entity in the user terminal, or by a network server — without continuously having to interact with the user. This is, in my opinion, the key issue.
Even more, sometimes the policies will not be defined “from scratch” by the user, but a good identity management product will come with predefined values, values that make sense for most of the users. For instance, my grandma might not be able to define each of the details by herself, she would appreciate some help.
Sometimes it is not a so good idea to give too much decision power to someone who doesn’t have enough information/ability to decide. Has anyone thought about this? – I hope nobody will call me fascist for it ;-).
BTW, my grandma’s answer to the question of an hypothetical user-centric system asking “Would you like to be consulted every time that anyone googles your name?” would be “Please……..NO!”.
If this is the definition of a “user-centric” system, sometimes I would prefer a “user-absent” one ;-) //carolina.
I have to agree that ‘user-centric’, to me, seems like a very “marketing-friendly” term (and as such, could be very useful, don’t get me wrong).
The bottom line is, it is very useful if you can designate (and sometimes enforce) who is in the driver’s seat for a given transaction. If it is a case where the user is initiating an internet transaction, they should be in the driver’s seat. If the user is an employee in a corporation, however, that user may happen to be utilizing technology that is “user-centric”, but really it is the corporation that is at the “center”, with the user simply along for the ride. In both cases, what I see as different here, compared to what exists today, is transparency between all parties as to who is control, and transparency to the user as to what data is being passed.
Um, not that this suggests to me a better name. I’m quite willing to use what’s already out there, and take liberties with it where necessary :-)
Pam
Sorry for getting late to this user-centric discussion. I liked the idea of making the user-centric term more specific and concrete. This is due to my frustration of seeing this term being used so loosely by everybody. I have put my thoughts together and would love to get feedback. To summarize my entry, I think that we need to define a way to measure the user centricity of the protocol and relationship that we are talking about. Would love to hear your thoughts.
The hard truth is:
(A) nobody agrees what “User Centric” should mean.
(B) almost everything will “break” if the user has to be the intermediary at run time. Web sites need to send us update emails, need to charge us subscription renewals, may be required by law to provide our address to police, etc etc: all of this must take place without the users presence.
Perhaps the best solution is to lobby for everyone to always clarify their meaning when using the term “User Centric” – if you mean “run time intermediary” – say so. If you mean access-policy architect, say it. If you mean any of the dozen or more other things I’ve read today – elaborate.
My personal understanding of what user-centric should mean is that other people are not allowed to keep any of my information about me in their “data silos”. I put my info into my ID provider, and anytime anyone else wants it, they have to come and get it. I can thus revoke access anytime I want, and audit the use of my info.