Tag Archives: VRM

How UMA deals with scopes and authorization

The UMA group has been quite busy of late. Like several other efforts (don’t miss John Bradley’s OpenID ABC post or anything Mike Jones has been blogging in the last few months), we’ve been gearing up for IIW 12 as a great place to try out our newest work, figure out the combinatorial possibilities with all the other new stuff going on, and get feedback.

Newcastle University’s SMART project team will be in Mountain View again, discussing their UMA implementation and UX work. And vice-chair Maciej Machulak and I plan to convene a session to share our draft solution for loosely coupling an OAuth authorization server and resource server to solve for externalized authorization and interoperable scoped access in the UMA context.

Back in February, a bunch of us tried discussing this very subject in Twitter and got pretty far, but it took Paul Madsen to put the whole story together in his blog post Way more than 140. And loving it. Check it out.

Essentially, UMA is choosing to give the host (resource server) more autonomy than it would typically have in a tightly coupled environment, so that it’s not entirely accurate to say it’s a mere policy enforcement point (PEP) and the authorization manager (authz server) is a full policy decision point (PDP). This seems to make good sense in a totally open-Web environment. However, “the full PDP” is an optional feature we could probably add if there’s interest.

The really interesting thing is that, to make externalized authorization work, we’ve had to go “radically claims-based”. The model seems very powerful and generative — it gives the power to upgrade and downgrade granted scopes at will! But it does take a step or two back from pure OAuth 2.0 as a result. This is something I’m keen to discuss with folks in and around IIW; we’ll be presenting these slides to that end.

People and online services: leaving value on the table

The recent Google-Facebook flap demonstrates that the hottest battleground for users’ control of the data they pump into these online services is the sites’ Terms of Service. Why? Because when you’re not a paying customer, you’re not in a hugely strong bargaining position. As I put it to ReadWriteWeb in their piece on data portability implications of the debate: Facebook’s end-users are not its customers; they’re the product. (Or as my Data Without Borders pal Steve Greenberg sometimes puts it, users are crops…getting harvested. Oh dear.)

For all “free” online services, it’s worthwhile to ask: What am I paying instead? If it’s not money, is it attention to ads? …behavioral cues about myself and my preferences? …personally identifiable data? …beta-testing time? …what, exactly? Payment for services rendered isn’t a bad thing. But it’s always something, and you might as well not be a chump.

That’s why I like Frank Catalano’s new TechFlash post viewing personal data sharing through an economic lens and discussing how to barter your data more equitably. Regarding his second point, “hide”: I’d actually be thrilled if more online services that were marketed to individuals offered a premium for-pay option; it would keep out the riff-raff and give people more meaningful control over their relationships with the companies offering the services.

It’s not just individuals who are leaving something on the table, though. I think there’s a big untapped market in selective sharing, which is like “privacy” (poor abused word), without the assumption that minimal disclosure is the be-all and end-all. What would you start sharing with a selective set of people and businesses, if you could have confidence that your expectations around context, control, choice, and respect would be met?

That’s why I think Dave McClure has it right with his notion of intimacy as a market opportunity Facebook currently has no idea how to address. (“maybe I only want to tell a few close buddies about that episode with the VERY BAD bean burrito” — yeah, thanks for keeping this sharing episode VERY selective. :-)

And that’s why I think Esther Dyson doesn’t quite have it right in saying privacy is a marketing problem. Her exhortation to “Know your customer, and talk to that person as an individual, not as someone in a bucket” has a natural barrier: Facebook and others are serving their actual customers very well indeed by, uh, making more product.

And that’s why I think User-Managed Access could help: Becoming paying customers of services that need our data is good. But becoming, in addition, producers of data products as peers in a selective data-sharing network, and dictating our own Terms of Access for getting to them, is even better.

Personal RFP Model and Information Sharing Report

The Kantara Information Sharing group, led by the intrepid Joe Andrieu and Iain Henderson, has been doing a ton of work to make the business justifications for Vendor Relationship Management scenarios concrete and and the use cases actionable.

The group has two documents out for review, and seeks your input. (I’m really tardy blogging this; comments are due tomorrow, but I’m sure they’d be welcome even coming in a little late…) See Joe’s writeup for document links and descriptions.

Here’s a taste of the pRFP document:

Sally uses a Personal Request for Proposal (pRFP) to solicit offers for, negotiate, and purchase a new car through the MyPal pRFP Broker. She has previously researched her options and made up her mind about the kind of car she wants to buy. She has also secured financing and credentials asserting that fact. Sally’s information is maintained in a personal data store which provides it on demand for use by service providers and vendors. On the Vendor side, Frank at Chryota of London responds to Sally’s Personal RFP (pRFP), using a hands‐on approach that integrates CoL’s CRM system, MyPal, and Chryota Manufacturing’s CRM program HEARING AID, which is managed by Jimmy.

The Info Sharing Report is interesting too, but in a totally different way; it’s chock full of interesting statistics and trends around the cost of acquiring customers and the privacy pitfalls of the current ecosystem.

Check ’em out, and send in your thoughts.

Both a data borrower and a data lender be

Christian Scholz and his Data Portability Project pals have roped me into their Data Without Borders podcasts. On Friday, Christian and Trent Adams and Steve Greenberg and I had some fun relaunching the series by talking about the DPP Terms of Service and End-User License Agreement (TOS/EULA) task force.

Steve was passionate in describing this work. I think he’s right when he says that you first have to ensure that people are aware of a site’s terms of service; disclosing them in a form human beings can grok (à la Creative Commons or the nutrition label approach I wrote about here) can begin to empower humans to change things if they so desire, using a variety of means.

At one point we talked about the Archive Team project run by Jason Scott, which I think of as “data portability of last resort”. These folks are like digital historian ninjas who swoop in to save data that might otherwise be lost forever — like everything on GeoCities.

The thing is, website-sanctioned bulk import and export of data isn’t all that huge an improvement on this kind of rescue operation. True data portability wants granularity and timeliness. For example, if you choose to host (so to speak) your current location info at FireEagle, you might still want to reuse it in other places for other purposes, and luckily OAuth lets FireEagle, Dopplr etc. give you a nimble and safe way to “port” this data back and forth.

This is a kind of data statelessness, in that when you tell various sites they can set, read, and republish your location, they’re letting go of any pretense of exclusive hosting control so that they can offer you a different kind of value.

Now, in the IdM and VRM worlds, some of us have been talking about identity statelessness for a while, which is similar but looks more like straight data-sharing (reading) rather than arbitrary service access (setting). For some reason this is a tougher sell — even though CRM systems and user accounts are shot through with pale copies of stale data (and, in the enterprise case, even though syncing directories and replicating databases is brittle and no fun).

Even when one party — say, you yourself — is authoritative for some piece of personal data (like your home address), all the sites insist on making you provision a copy of this data into their profile pages by hand and by value, and insist on thinking they own something truly valuable even after you move and forget to tell them.

In short: To the extent data is volatile, copies of it leak value. If the chain of evidence between its authoritative source and a recipient of data is broken, it quickly becomes value-free. And if the chain of authorization breaks, you’ve got digital shadow cruft. Why oh why can’t we get to a place where, as Scott Cantor put it to me once, identity-aware apps think in terms of data caching rather than data replication?

The Data Portability TOS/EULA work is helping us raise our standards for what true data portability should look like: Open Arms – Ever Fresh – Graceful Exit. OAuth already helps us get a bit beyond disclosure of site terms, closer to a world where users have an active say in what sites do with our stuff. I’m hoping UMA (recent deep-dive Technometria podcast here) can help us go even further because of its notion of user-dictated terms that recipients must meet in order to have the privilege of fresh access.

We’re likely to discuss this topic in the DWB podcast sometime soon, so I hope you’ll give a listen.

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.

ProtectServe: getting down to (use) cases

The need for permissioned data-sharing and relationship management doesn’t discriminate in favor of, or against, any type of entity; the stick figures below, representing a data-discloser and a data-consumer, could be a big company and one of its suppliers (B2B), or a company and one of its customers (B2C), or a customer and one of the vendors in her life (C2B), a citizen and one of the government agencies he deals with (C2G), etc.


The process wants to become more “peer-to-peer” (P2P!) than it is today. Data-disclosers, often disadvantaged today because they’re pressured to over-disclose and under-enforce, need to be empowered in a more balanced way. But while we’d like our ProtectServe and Relationship Manager architecture to be suggestive for the general case, we had to get specific, and so our initial use cases involve a data-disclosing human being and a data-consuming web app; you can think of them as playing the roles of “customer” and “vendor” in VRM scenarios such as change-of-address.

Here were our major functional requirements:

  • Allow individuals to establish policies for each data-sharing relationship they have, as an interface mode separate from the login process
  • Allow individuals to conduct long-term relationship management, including modifying the conditions of sharing
 or terminating the sharing relationship entirely
  • Allow data recipients to retrieve data directly from authoritative sources, guided by policy, even while an individual is offline, reserving approval loops for extraordinary circumstances
  • Allow data recipients to retrieve individuals’ data from multiple online sources, on a one-time or repeated basis
  • Do this simply enough to attract adoption and energy

Obviously these requirements drive a lot of decision-making all by themselves, but soon enough even more specificity is needed. And that’s where Bob Blakley comes in. Bob kindly provided a lot of detailed feedback to me recently on our ProtectServe user experience mockups. In the course of our chat, he nicknamed two distinct use case categories we were hoping to solve for, which clarified my thinking in a big way.

One set of use cases involves a User explicitly provisioning a Consumer app with a way to get some set of data. For example:

  • Registering for a new online account (or even buying something on a “one-night stand” basis, with no ongoing account) and providing stock info like a shipping address and credit card data (likely packaged into a set somehow)

  • Providing calendar data to businesses to solicit event invitations (cable customer service, dentist’s appointment), or — in the case of travel calendars — to control mail/package/newspaper delivery or solicit travel-related offers of products and services (like country-specific prepaid calling cards)

  • Making home inventory data available to insurers, or to estate-sale catalogue assemblers

  • Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group
  • (Warning: meta-example!) Serving out some cooked form of Relationship Manager audit-log data to a company that builds reputation scores for Consumer apps

Noting that the user is fully in charge, and no Consumer even learns about the data’s availability without the User’s personal and active involvement, Bob gave this set of use cases the Delta Tau Chi name of Data Dominatrix.

We also worked with a secondary bucket of use cases, though it has presented us with interesting protocol and user experience difficulties: widely publishing the existence of data, then deciding whether to to release it on request (where the requests were not individually solicited). For example:

  • Putting links to your calendars, vCards, etc. on your blog, and then fielding requests from every party that wants it

  • Offering a package of demographic data about yourself to any survey service willing to pay your price

In his inimitable way, Bob named this one Hey, Sailor. (Hmm, I’m sensing a theme here. What sort of girl does he think customers are? Then again, it doesn’t help that sometimes we want “one-night stands” in our online relationships!)

These use cases affected our choices around things like:

  • The dynamic nature of the introduction process between Consumers and other parties
  • The granularity of contract terms as they apply to data resources
  • Where users need to be involved real-time vs. where they at least want the option of real-time consent vs. where they don’t want to be bothered

By the way, we also discussed a third use-case bucket that has not been on my team’s radar, and which I don’t believe got a nickname: The User puts together a prospectus of data he’s willing to assemble, if the right offer is made by a potential Consumer. While this sounds very interesting, there are already enough business and technical question marks around the rest of the proposition to make me want to hold off. But hey, if anyone’s inspired to defend it (or name it!), let me know.

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.


Mydex demo: lovely identity harmonics

Asa Hardcastle, OpenLiberty rock star, has posted some details on an exciting demo he’s put together on behalf of Mydex.

The demo is a pretty sophisticated combination of identity-related technologies: information cards for authentication and transfer of service-bootstrapping info; XRI for keying into the Mydex personal datastore and some user-driven services; the Identity Web Services Framework (ID-WSF) for pointing off to other loosely coupled services; and SAML as the (ahem) “universal-solvent” assertion format. The use case being addressed here illustrates what, to me, is an important point: we are going to need both front-channel (through the user/user agent) and back-channel (service-to-service) data sharing in the real world, and our identity-enabled architectures need to empower individuals as fully as possible even in the latter case.

Iain Henderson of Mydex is plumbing an interesting issue in Vendor Relationship Management; he calls it Volunteered Personal Information or VPI. Iain’s VPI Special Interest Group is currently working on encapsulating an individual’s contract terms for data-sharing, and I believe this work will ultimately apply to the entire VRM problem space and, indeed, to all cases of “free-agent” identity on the ‘net. Check it out!

Where should data live? (part two)

Yesterday I said “you might have reasons for choosing different hosts for information that has different levels of sensitivity [or] needs for high-availability access”. Today I happened to run across a company that makes a business out of this:

The DocuBank Emergency Card provides immediate access to your healthcare directives, any time, anywhere they are needed.

DocuBank provides access to the following critical documents: Living Will, Health Care Power of Attorney, HIPAA release, organ donation form, hospital visitation forms, burial instructions and more. DocuBank makes your healthcare directives work.

They give you a card for your wallet that acts as the “discovery service” to get to the documents, and you need to have authorization to see them: either they’re about you, or you’re a healthcare provider who has specially registered to get access to this type of information.

Poking around online, I also just learned about the Washington State Living Will Registry, which seems to function much the same except that it’s run by the state.

I’m glad there’s a choice of providers for healthcare directives in break-glass scenarios — and I’m also glad I don’t have to host such information myself on the computer under my desk. After all, I could never offer myself a service-level agreement that I’d find acceptable…

Where should data live?

George Fletcher provides interesting commentary on a good social-web discussion by Om Malik. The issue: Whether aggregation and federation of data are opposite, or complementary.

George says:

[F]or aggregation to work in the “open web”, it must be able to access my data whereever I’ve chosen to place it.

I agree. If we’re looking to empower people, it’s not realistic to insist that all their information live in a single place. Just as inventing a new identifier type isn’t sufficient to eliminate all the various identifiers we already have in our lives — there are good reasons, not just legacy reasons, to have more than one — solving the problem of storing everything in one place isn’t sufficient to eliminate all the places information about us is stored. Here are two non-legacy reasons.

First, you should be able to choose (as George says) where to store information you created, and you might have reasons for choosing different hosts for information that has different levels of sensitivity, needs for high-availability access, needs for fine-grained access control specific to certain data types, etc. There needs to be an option not just to import/export everything en masse from one competing hosting environment to another, but also to tolerate multiple sources of data at once. It almost feels anti-web to prefer an architecture that requires everything to live together on one server.

Second, it doesn’t make sense to throw information about you for which you’re not authoritative (like your credit score, or really any reputation data) into one aggregation pile; you can’t control the value, but it’s still “yours” in lots of other senses. You might have the right to track who sees it, but a live copy shouldn’t reside in your one big database where you have write access. (I liked Gerry Gebel’s insight around this: Try to think of any application that relies on data from elsewhere to be stateless with respect to it. Another way to think about it is that you want to achieve a sort of “first normal form”, where information properly lives wherever its authoritative source chooses it to live.)

George notes that if you can authorize a relying party to get the data from whatever your preferred source is, you can get the best of both worlds. It’s aggregating some parts of data provisioning, usage, and auditing, but not the actual residence of the data.

I’ve become convinced that multi-sourced data access is a requirement for the core permissioned data sharing issue that’s common to identity, VRM, and social networking use cases.

I happened to do a webcast yesterday that describes the VRM proposition — you can watch the recording if you register for a free account — and I went into a bit of detail about the technical requirements I see, along with reviewing some of the architectures at our disposal for achieving them. (The good news is, there are already several…) [UPDATE: Slides are now available here.] I think I need to start adding this requirement to my list.