Tag Archives: ProtectServe

UMA learns how to simplify, simplify

It seems like a good time to review where we’ve been and where we’re going in the process of building User-Managed Access (UMA).

The introduction to our draft protocol spec reads:

The User-Managed Access (UMA) 1.0 core protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that makes access decisions based on user policy.

For example, a web user (authorizing user) can authorize a web app (requester) to gain one-time or ongoing access to a resource containing his home address stored at a “personal data store” service (host), by telling the host to act on access decisions made by his authorization decision-making service (authorization manager). The requesting party might be an e-commerce company whose site is acting on behalf of the user himself to assist him in arranging for shipping a purchased item, or it might be his friend who is using an online address book service to collect addresses, or it might be a survey company that uses an online service to compile population demographics.

While this introduction hasn’t changed much over time, the UMA protocol itself has undergone a number of changes, some of them dramatic. The changes came from switching “substrates”, partly in response to the recent volatility that has entered the OAuth world with the introduction of WRAP and partly in an ongoing effort to make everything simpler.

Here’s an attempt to convey the once and future UMA-substrate picture:


Back in the days of ProtectServe, we did try to use “real OAuth” to associate various UMA entities, but in one area we “cheated” (that is, used something OAuth-ish but not conforming) to get protocol efficiencies and to ensure the privacy of the authorizing user. Hence the wavy line.

Once the UMA effort started in earnest at Kantara, we discovered a way to use three instances of “real OAuth” instead, and decided to (as we thought of it) “get out of the authentication business” entirely — thus theoretically allowing people to build UMA implementations on top of OAuth as a fairly thin shim. However, the trick we had discovered to accomplish this, along with (it must be admitted) an over-enthusiasm for website metadata discovery loops, made the spec pretty dense and hard to understand and we weren’t satisfied with that either.

As of last week, we have moved to a WRAP substrate on an interim basis, and that approach is what’s in our spec now. Although WRAP’s entities sound an awful lot like UMA’s entities (authorization manager/authorization server, host/protected resource, requester/client, authorizing user/resource owner), it took us a while to disentangle the different use cases and motivations that drove the development of each set, and in retrospect I’m glad we don’t have the same exact language. It allows us to have a meaningful conversation about the ways in which WRAP can gracefully assume a “plumbing” role for UMA (and other) use cases, and the ways in which we need to extend and profile it.

Here’s a diagram that summarizes the current state of the UMA protocol and the role(s) WRAP plays in it (click to enlarge):

UMA protocol summary

Given our use cases, it pretty much flows naturally, and it solves the problems we were previously tying ourselves in knots over. (Do check out the details if you have that sort of inquiring mind. Though reading our spec now benefits from an existing understanding of the WRAP paradigm — we plan to add more detail to make it stand better on its own — it’s now a lot more to-the-point.)

So all in all, I’m very pleased about our direction, and about the increasing interest we’re seeing from all over the place. But we’re not there yet, and it’s partly because over at the IETF they’re still working on OAuth Version 2.0, and that’s what we’re really after. We have been active in contributing use cases and feedback to the OAuth WG, and I think next week’s meeting at IETF 77 will be productive for all.

Come to the Kantara UMA workshop at the beginning of the European Identity Conference on May 4! (fixed; used to say May 3)

Though UMA isn’t fully incubated yet, it also seems like a good time to give a shout-out to all the UMAnitarians (join us… don’t be afraid…) who are helping with the process, with special thanks to our leadership team: Paul Bryan, Domenico Catalano, Maciej Machulak, Hasan ibne Akram, and Tom Holodnik.

Privacy nutrition labels

The recent Symposium on Usable Privacy and Security, SOUPS 2009, seemed to cover a whole lot of interesting topics. One of these days I hope to attend for real — but failing that, I’m just working my way through the proceedings slowly. One paper, A “Nutrition Label” for Privacy, is especially cool.

The researchers have gotten pretty far down the path of rationalizing website privacy policies into a graphical/tabular form that’s actually enjoyable to use (their word! and they have numbers to back it up!). Whereas such policies in natural-language form are usually wordy, complex, inconsistent, and stubbornly irrelevant to a user’s actual preferences, their proposed label format provably borrows the benefits of real U.S. FDA nutrition labels, such as making a policy more amenable to at-a-glance interpretation, allowing you to compare two policies, and providing visual boundaries for the regulated/trustable portion of what you’re seeing.

The data categories in the label are a very high-level, “cooked” version of what’s in the Platform for Privacy Preferences (P3P) policy system. It’s worthwhile asking if the labels, and even the original sophisticated descriptions of data collection and use that they’re based on, are measuring the right thing. (After all, I have very little confidence that actual FDA Nutrition Facts labels are measuring the right thing.) But the categories they list seem like a pretty good start; “your activity on this site”, for example, turns out to be one of the biggest loopholes in many of today’s prolix-but-slippery privacy policies:

  • contact information
  • cookies
  • demographic information
  • financial information
  • health information
  • preferences
  • purchasing information
  • social security number & govt ID
  • your activity on this site
  • your location

Now I’m consumed by the thought of letting a person use this matrix-based approach to configure her ProtectServe-enabled relationship manager, such that any would-be recipient has to meet her privacy terms if they want to get the goods…

Making change

So last week I made a big transition, joining Andrew Nash‘s identity services team at PayPal. (And I kind of told Twitter about it before I told y’all. Sorry about that; it’s the nature of the communications beast.) Working with Andrew, Ashish, and other great folks at PayPal is going to be a blast. And it’s an especially interesting time to shift from a technology-stack-providing world to a consumer-facing one.

Being with Sun Microsystems for ten years was an honor and a pleasure; I got to work closely with some of the most talented and interesting folks in the business. And during that time my experiences helped me layer new personae onto “old SGMLer”: “XMLgrrl”, “the SAML lady”, and even, ahem, “the queen of Venn”.

You’ll still find me involved in some familiar activities — for example, I remain involved in ProtectServe and User-Managed Access efforts, and I hope to keep up my fledgling Tek-Tips video-blogging series on identity and the cloud (#1 on the relevance of federated identity to cloud computing, #2 on the challenges of passwords for authenticating to cloud services).

Thanks for continuing to witness my pushing of string over here. I plan to continue blogging my thoughts on matters of identity, security, privacy, and trust (and occasionally nutrition, music, and knitting…), and look forward to your feedback. You can find fresh contact and bio information on my welcome page; drop me a note anytime.

Concordia workshop: the secret word is authz

Dave Kearns asks, I deliver — in two parts (so far)…

Concordia workshop report

Monday’s Concordia workshop at Catalyst was a surprise and a delight. We tried to make it a more interactive and intimate experience than the mega-carnivals we do at RSA: check. We set up a theme — identity in Enterprise 2.0 — and hoped for a bunch of interesting use-case submissions to tee up the subject: check. We worried that the diverse agenda would hang together: we needn’t have. A leitmotif emerged pretty quickly: authorization.

A crack team of volunteer tweeters, led by Brett McDowell (in English; I helped!) and Tatsuo Kudo (in Japanese), helped keep the outside world connected to our discussions (searching #catalyst09 concordia gives you an accessible sampling, but looking for tweets on July 27 for just #catalyst09 will give a more complete listing).

All presentations and original sources are now linked from the workshop agenda, and I strongly encourage you to check out this rich material. Attendees were enthusiastic about the new XACML profile work and our Burton speakers’ thoughts on the complexity of social networking in enterprise settings (thanks again to Mike Gotta and Alice Wang for presenting some exciting/scary scenarios, and to Burton as a whole for continuing to support our Concordic efforts). And people had lots of useful feedback on the Levels of Assurance survey idea we’ve been hammering on for a couple of months now — basically, we think we’re going to start with in-depth interviews instead, since all our questions are open-ended and lead to more questions.

If you want to help us figure all this out going forward — including possibly contributing multi-technology authorization use cases for future interop experimentation — don’t forget to join Concordia in its new guise as a Kantara discussion group! Here are simple instructions.

ProtectServe and UMA deeper dive

At the workshop I had a great opportunity, given that my User-Managed Access group is just spinning up, to do a quick overview of the ProtectServe work that has inspired UMA and to review some alternative “use-case topologies” that could satisfy a single generic scenario in different ways. Srijith Nair et al. of BT submitted an interesting ProtectServe use-case document, and in my workshop presentation I walked through some of the implications.

The scenario I highlighted is about an employer and an employee, and the fact that both might want to impose their own constraints on the sharing of the same piece of information. Examples of pieces of information your employer holds that you might need to share (the Liberty ID-SIS employee profile spec might suggest more):

  • Employment status (often needed when you apply for a loan)
  • U.S. Internal Revenue Service W-4 (tax withholding) form details (handy for sharing with accountants and investment planners)

I (sort of ab)used the Scrum concept by formulating the following “user stories” that capture what’s special about the need:

  • As an employee, I want to audit and control the further dissemination of information my employer must know about me as a condition of employment.
  • As an employer, I want to adhere to laws and best practices regulating my sharing of information about my employee.

Three obvious ProtectServe entity topologies present themselves, each with a different sweet spot:

#1: Employer as authorization manager and service provider

This topology preserves an explicit place for the employer to apply its own sharing policies — the authorization manager (and enclosing relationship management app) that it hosts itself. However, I think this is probably a “legacy” solution because it forces the employee to seek out other relationship managers in the outside world where they’re just an individual rather than an employee, and I can’t think of very good reasons for the employer to host this AM/RM other than corporate inertia (admittedly, a force to be reckoned with). Maybe I’m wrong, though, and a good reason will emerge.

#2: Employer as service provider

For information for which the employer is authoritative (“Is this person employed here?”), it should host a service provider willing to attest to this on request (in accordance with the instructions issued by the employee’s personal AM). If the employer doesn’t want to release the data even though the employee is cool with the sharing, it could use existing access control mechanisms that are out of band with respect to ProtectServe, perhaps only surfacing a response code that reflects its refusal. (Ah, there’s a potential requirement for the UMA work if this use case is accepted by the group.)

#3: Employer as consumer

For information that the employee already self-asserts to the employer (“What is the employee’s home address of record?”), why can’t the employer consume this data in the same way some other “vendor” (online service) on the open Internet could? If the employee moves, a number of workflow actions have to unroll on the employer’s side as they would have anyway (in the U.S., moving to a different state might involve withholding a different amount of state income tax), but this is already handled in existing systems when the employee provisions the new information into employee portal apps by hand. An on-board “personal datastore” service provider is shown here as being hosted out of the same relationship manager app as the user’s chosen AM, but the SP could just as easily have been hosted remotely somewhere.

If you have thoughts on this, either about the problem space or the solution space, please consider joining the UMA group and helping out!

ProtectServe news: User-Managed Access group

After a few weeks’ worth of charter wrangling, I’m delighted to announce the launch of a new Kantara Initiative work group called User-Managed Access (UMA). Quoting some text from the charter that may sound familiar if you’ve been following the ProtectServe story:

The purpose of this Work Group is to develop a set of draft specifications that enable an individual to control the authorization of data sharing and service access made between online services on the individual’s behalf, and to facilitate the development of interoperable implementations of these specifications by others.

Quite a few folks have expressed strong interest in using this work to solve their use cases and in implementing the protocol (speaking of which, sincere thanks to the dozen-plus people who joined with me in proposing the group). With a basic design pattern that is as generative as ProtectServe seems to be, and with the variety of communities we’ll need to engage, it could be tricky to stay focused on a core set of scenarios and solutions, but I intend to work hard to do just that. Better to boil a small pond than…well, you know. Stay tuned for more thoughts on how I think we can accomplish this.

If you’d like to contribute to the continuing adventures of ProtectServe, please check out the User-Managed Access WG charter and join up! Here’s where to go to subscribe to the wg-uma list, which is read-only by default, and to become an official participant in the group, which gains you list posting privileges. (In case you’re wondering, there is no fee whatsoever for Kantara group participation.)

By the end of this week we’ll start using the list to figure out a first-telecon time slot, and I’ll provide updates on various group milestones here. If you’ve got any questions at all, feel free to drop me a line.

To protect and to serve

To protect and to serve

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.