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.