In the last year, I’ve done a lot of thinking about the permissioned data sharing theme that runs through everything online, and have developed requirements around making the “everyday identity” experience more responsive to what people want: rebalancing the power relationships in online interactions, making those interactions more convenient, and giving people more reason to trust those with whom they decide to share information.
In the meantime, I’ve been fortunate to learn the perspectives of lots of folks like Bob Blakley, Project VRM and VPI participants, e-government experts, various people doing OAuth, and more.
Together with some very talented Sun colleagues (special shout-out to team members Paul Bryan, Marc Hadley, and Domenico Catalano), I started to get a picture of what a solution could look like. And then we started to wonder why it couldn’t apply to pretty much any act of selective data-sharing, no matter who — or what — the participants are.
So today I’m asking you to assess a proposal of ours, which tries to meet these goals in a way that is:
- simple
- secure
- efficient
- RESTful
- powerful
- OAuth-based
- identity system agnostic
We call the web protocol portion ProtectServe (yep, you got it). ProtectServe dictates interactions among four parties: a User/User Agent, an Authorization Manager (AM), a Service Provider (SP), and a Consumer. The protocol assumes there’s a Relationship Manager (RM) application sitting above, acting on behalf of the User — sometimes silently. At a minimum, it performs the job of authorization management.
We’re looking for your input in order to figure out if there are good ideas here and what should be done with them. (The proposal is entirely exploratory; my employer has no plans around it at the moment, though our work has been informed by OpenSSO — particularly its ongoing entitlement management enhancements.)
Read on for more, and please respond in this thread or drop me a note if you’re interested in following or contributing to this work. If there’s interest, we’re keen to join up with like-minded folks in a public forum.
Here’s what we’re imagining the user experience to be like. Click on the graphic to see a series of mockup screenshots:
And here’s a buffet of analogies to choose from in relating ProtectServe and the Relationship Manager notion to concepts you might already know:
-
If you’re an OAuth aficionado, ProtectServe is something like four-legged OAuth or higher-order OAuth, with the effect of separating out an authorization job for the Relationship Manager that today’s OAuth SPs do all by themselves.
-
If you’re an enterprise IT type, ProtectServe is a bit like RESTful XACML, with the Relationship Manager serving as a policy decision and administration point (PDP and PAP) and SPs serving as policy enforcement points (PEPs).
-
If you work on VRM solutions, you might think of a Relationship Manager as a kind of virtual personal datastore, and possibly a literal one as well (not shown in the mockups yet — stay tuned).
-
If you are familiar with the Liberty Web Services, particularly the RESTful ID-WSF work, ProtectServe could be seen as a Discovery Service complement that helps a user manage access to her various identity-data-providing services.
-
If you’ve been following along with OpenID extension work, the offering and acceptance of contract terms is sort of a user-driven analogue of OpenID Contract Exchange.
And now I really want to share the ProtectServe protocol design with you, especially to show off the contract offer/acceptance stuff, which happens largely under the covers. But…we’ve recently done some work on the protocol to leverage OAuth as closely as humanly possible, and in fairness I want to give our little team a chance to comment on the new changes first. I promise to provide the flows here shortly.
There’s actually a ton more background information (and questions) I’d love to provide — not just about the protocol design challenges but also about potential futures for Relationship Managers, design goals and rationales, security models, and more. But let’s take this one step at a time. Interested to learn more and share feedback? Let me know.
RESTful is way cool. But I wonder, why do you see it as a goal or preferred?
It’s an interesting scheme, certainly, but what does it give me that InfoCards don’t already handle?
-dave
Hi Phil,
One answer is that the problem space is about doing distributed authorization for everyone and everything on the web (to be grandiose about it :-), so it makes sense to use an architectural style that’s well matched and intimately associated with the web.
A more specific answer is that REST scales and is “generative” in an appealing way, making lots of use cases possible even if they weren’t envisioned or catered to originally. E.g., if you want to recursively protect anything in our protocol flow that’s a web resource (like contract terms), you can do it.
In the context of VRM, another answer is that customer empowerment comes partially from “turning the customer into a platform.” The question then becomes, “What platform?” REST is an accessible development approach that seems to spur wider adoption than the alternatives. The smart way to bet is further consumerization of IT, not ITization of consumers! I’ve been particularly inspired by the example of the “protocol” used today when people authorize other people to see their calendars and photos selectively, through e.g. Google and Flickr. It’s all about managing access to web resources, without the need for some huge bespoke protocol that’s specific to the format of what’s being exchanged.
(The flip answer, which Tim Bray gave a few days ago, is that “REST isn’t good because it’s REST, it’s good because it’s good.” :-)
Hi Dave,
Lots. I think infocards can be a useful adjunct to the user-experience portion of distributed authorization, e.g. passing along an RM location claim when you log in to an SP to give it a hint as to your preferred RM. (This would be akin to the use of infocards to pass along a Liberty Discovery Service bootstrap attribute, as was demonstrated just recently.)
But infocard usage is predicated on real-time user consent for claim access (r-cards being the potential exception) vs. access when a user is offline; selectors don’t have analytics features (though why not, I don’t know); the protocol focuses on mere user consent — likely pro forma — rather than an offer of data under user-driven contract terms; and in most use cases cards typically pass along an identifier as one of the claims, which can unnecessarily early-bind that identifier to that set of shared data.
All this said, hosted identity selectors would perhaps make a fine starting place for building relationship managers…
Hi Eve,
I am driven to respond to your “turning the customer into a platform” quote; something is bugging me about it.
I think it’s the difference between “turning people into predetermined X” versus “giving people new capabilities” – I go for the latter because I believe that VRM is not about turning people into robots which are better equipped to buy stuff – but instead I believe it’s about putting ordinary people on parity with the rest of the commercial world’s technology, and giving them control.
That may be phrased as turning them into a platform, I suppose – but I don’t see “platforming” as the predetermined or inevitable outcome.
As for the software I appreciate where you are trying to go and why, and I find it very interesting – for obvious reasons I prefer The Mine Project’s approach to the problem, as written-up at http://themineproject.org/index.php/mine-papers/ (though the paper needs a refresh to match the implementation) – because I don’t like unnecessary multiplication of intermediaries, in fact I prefer to reduce them. :-)
But it is very interesting.
Best wishes,
– alec
Hi Alec– Thanks very much for your comments and your interest!
Yes indeed, the phrase “turning people into X” is a bit infelicitous, though I was just picking up on other usages I’ve seen in the VRM context. In a previous preso (see slide 13), maybe I did a better job of this, discussing the pair of asymmetries going on here: a customer needs to be able to face vendors more as if he/she were a big web server, and a vendor needs to face customers more as if it were an individual.
My intent is that our approach is compatible with the Mine approach, in that a Relationship Manager could itself be a service provider for any data the user cares to self-host, with Atom feeds in particular — even if their entries point to data residing elsewhere — being a natural fit. Our assumption has been that an individual’s data may continue to be multi-sourced for a long time, and so it’s convenient to get the benefits of an authorization hub even if the data isn’t kept at the same place.
In our work, we’re finding that, with a set of clearly defined entities and a clear protocol between them, it becomes possible to compare architectural approaches that choose to co-locate two or more of the entities. Stay tuned for some comparative diagrams on that very soon.
“In our work, we’re finding that, with a set of clearly defined entities and a clear protocol between them, it becomes possible to compare architectural approaches that choose to co-locate two or more of the entities. Stay tuned for some comparative diagrams on that very soon.”
In plain english, that means “we think that the thing to do is tie together the relationships between separate services and/or objects, rather than centralise them” – yes?
Alec– Thanks for the reminder to blog more about that. Will try to get to that today. I’m not sure I understand your paraphrase…sorry about that. But here’s another brief attempt:
If you define a useful set of conceptual entities and the canonical communications between them, then you have an interesting new tool for describing deployment scenarios where multiple entities live in the same “software body” vs. where they don’t.
A non-ProtectServe-related example is the concept of a “user agent” communicating with an HTTP server. By defining the basic communication mechanisms of a user agent, you can discuss browsers, RIAs, and various other software that embeds (maybe multiple) user-agent interfaces more intelligently.
This isn’t an original point, I’ll admit. :-) It’s just a consequence of protocol design.
While I’m happy to see you use my photo, I would appreciate it if you could follow the guidelines of the CC license that is attached to it.
Hi Steve– I apologize; I missed seeing the specific attribution instructions you had provided. I’ve added the attribution (and appreciate the opportunity to correct my usage of your content, following the permissioning policies you had laid out, given the subject of the post!).
Hey, no worries – Flickr’s setup isn’t exactly user-friendly, and I didn’t mean to come across as gruff as my previous comment sounds. What I normally see people who use my photos do is drop a much smaller version of what you added just under the photo, which would probably look a lot nicer in your post.
Anyway, thank you for the quick response.
Thanks for your good nature about this! :) Actually, Flickr makes an interesting case study for the ideas I’ve been pursuing with this ProtectServe thingie (now being worked on as UMA). I like that Flickr lets me search only for content that I’m legally able to use, but CC is only expressed as a unilateral policy rather than as something I need to positively agree to before I use the image. (In our UMA effort, we should probably think about whether we can make a hot-linking use case, like the above, work.)