Paul Madsen has a knack for pithy identity wisdom. But his recent piece on HealthVault's use of OpenID made me do a double take.
“Simon Willison defends HealthVault‘s choice of OPs [OpenID providers – Kim].
“I disagree. It is I, as a user, that should be able to dictate to HealthVault the OPs from which they are to accept identity assertions through OpenID.
“Just as I, as a user of Vista, should be able to dictate to Microsoft which software partners they work with to bundle into the OS (I particularly like the Slow Down to Crawl install).
“Just as I, as a Zune user … oh wait, there are no Zune users….
“The mechanism by which I (the user) am able to indicate to HealthVault, or Vista, my preferences for their partners is called ‘the market‘.”
Hmmm. All passion aside, are Vista and HealthVault really the same things?
When you buy an operating system like Vista, it is the substratum of YOUR personal computer. You should be able to run whatever YOU want on it. That strikes me as part of the very definition of the PC.
But what about a cloud service like HealthVault? And here I want to get away from the specifics of HealthVault, and talk generically about services that live in the cloud. In terms of the points I want to make, we could just as easily be talking about Facebook, LinkedIn, Blogger or Hotmail.
As a user, do you own such a service? Do you run it in whatever way you see fit?
I've tried a lot of services, and I don't think I've ever seen one that gives you that kind of carte blanche.
Normally a service provides options. You can often control content, but you function within parameters. Your biggest decision is whether you want to use the service in the first place. That's a large part of what “the market” in services really is like.
But let me push this part of the discussion onto “the stack” for a moment.
Last week a friend came by and told me a story. One of his friends regularly used an Internet advertising service, and paid for it via the Internet too. At some point, a large transaction “went missing”. The victim contacted the service through which he was making the transaction, and was told it “wasn't their problem”. Whose problem was it?
I don't know anything about legal matters and am not talking from that point of view. It just seems obvious to me that if you are a company that values its relationships with customers, this kind of breach really IS your problem, and you need to face up to that.
And there is the rub. I never want to be the one saying, “Sorry – this is your problem, not ours.” But if I'm going share the problem, shouldn't I have some say in preventing it and limiting my liability?
I think that someone offering a service has the right to define the conditions for use of the service (let's for now ignore the fact that there may be some regulation of such conditions – for example certain conditions might be “illegal” in some jurisdictions). And that includes security requirements.
In other words, matters of access control proceed from the resource. The resource decides who can access it. Identity assertions are a tool which a resource may use to accomplish this. For years we've gotten this backwards, thinking access proceeded from the identity to the resource – we need to reverse our thinking.
Takeaway: “user-centric” doesn't mean The Dictatorship of the Users. In fact there are three parties whose interests must be accomodated (the user, the resource, and the claims provider). At times this is going to be complex. Proclamations like, “It is I, as a user, that should be able to dictate…” just don't capture what is at stake here.
I like the way Simon Willison puts this:
“You have to remember that behind the excitement and marketing OpenID is a protocol, just like SMTP or HTTP. All OpenID actually provides is a mechanism for asserting ownership over a URL and then “proving” that assertion. We can build a pyramid of interesting things on top of this, but that assertion is really all OpenID gives us (well, that and a globally unique identifier). In internet theory terms, it’s a dumb network: the protocol just concentrates on passing assertions around; it’s up to the endpoints to set policies and invent interesting applications.
“Open means that providers and consumers are free to use the protocol in whatever way they wish. If they want to only accept OpenID from a trusted subset of providers, they can go ahead. If they only want to pass OpenID details around behind the corporate firewall (great for gluing together an SSO network from open-source components) they can knock themselves out. Just like SMTP or HTTP, the protocol does not imply any rules about where or how it should be used…”
In a later post – where he seems to have calmed down a bit – Paul mentions a Liberty framework that allows relying parties to “outsource the assessment of… OPs to accredited 3rd parties (or at least provide a common assessment framework…)”. This sounds more like the Paul I know, and I want to learn more about his thinking in this area.