User control is central tenant of any online world that most of us will want to live in. You don't have to consider things like surveillance-based marketing or devices that spy on us long to realize that a future that's an extrapolation of what we have now is a very real threat to personal autonomy and freedom.

A key part of the answer is developing protocols that make it easy to give control to users.

The Limitations of OAuth

Even if you don't know what OAuth is, you've likely used it. Any time you use Twitter, Facebook, or some other service to login into some other Web site or app, you're using OAuth. But logging in is only part of the story. the "auth" in OAuth doesn't stand for "authentication" but "authorization." For better or worse, what you're really doing when you use OAuth is your granting permission for the Web site or app that's requesting you "log in with Facebook" to access your Facebook profile.

Exactly what you're sharing depends on what the relying site is asking for and what you agree to. There's usually a pop-up or something that says "this app will be able to...." that you probably just click on to get it out of the way without reading it. For a fun look at the kinds of stuff you might be sharing, I suggest logging into Take This Lollipop.

But while I think we all need to be aware that we're granting permissions to the site asking us to "log in," my purpose isn't to scare you or make you think "OAuth is bad." In fact I think OAuth is very, very good. OAuth gives all of us the opportunity to control what we share and that's a good thing.

OAuth is destined to grow as more and more of us use services that provide or need access to APIs. OAuth is the predominant way that APIs let owners control access to another service.

But OAuth has a significant limitation. If I use OAuth to grant a site to access Twitter, the fact that I did so and my dashboard for controlling it is at Twitter. Sounds reasonable until you imagine OAuth being used for lots of things and the user having dozens of dashboards for controlling permissions. "Let's see...did I permission this site to access my Twitter profile? Facebook? BYU?" I've got to remember and go to each of them separately to control the permission grants. And because each site is building their own, they're all different and most aren't terribly sophisticated, well-designed, or easy to find.

User-Managed Access to the Rescue

The reason is that while OAuth conceptually separates the idea of the authorization server (AS, the place granting permission) and the resource server (RS, the thing actually handing out data), it doesn't specify how they interact. Consequently everyone is left to determine that for themselves. So there's really no good way for two resources, for example, to use a single authorization server.

That's where UMA, or User-Managed Access, comes in. UMA specifies the relationship between the AS and RS. Further, UMA envisions that users could have authorization servers that are independent of the various resources that they're granting permission to access. UMA has been a topic at Internet Identity Workshop and other places for years, but it's suddenly gotten very real with the launch of ForgeRock's open-source OpenUMA project. Now there's code to run!

Side note: If you're a developer you can get involved in the UMA developer working group as well as the OpenUMA effort depending on whether your interests lie on the client or server side.

With UMA we could each have a dashboard, self-hosted or run by the vendor of our choice, where we control access permissions. This may sound complicated, like a big mixing board, but it doesn't have to be. Once there's a single place for managing access, it's easier for default policies and automation to take over much of the busy work and give owners better control at the same time.

UMA and Commerce

Doc Searls coined the term "vendor relationship management" or VRM years ago as a play on the popular customer relationship management (CRM) tools that businesses use to manage sales and customer communications. It's a perfect example of the kind of place where UMA could have a big impact. VRM is giving customers tools for managing their interactions with vendors. That sounds, in large part, like a permissioning task. And UMA could be a key piece of technology for unifying various VRM efforts.

Most of us hate seeing ads getting in the way of what we're trying to do online. The problem is that even with the best "targeting" technology, most of the ads you see are wasted. You don't want to see them. UMA could be used to send much stronger signals to vendors by granting permission for them to access information would let them help me and, in the process, make more money.

For example, I've written about social products. Social product provide a link back to their manufacturer, the retailer who sold them, the company who services them, and so on. These links are permissioned channels that share information with companies that tell them what products and services I need.

UMA is a natural fit for managing the permissions in a social product scenario, giving me a dashboard where I can manage the interactions I have with vendors, grant permission for new vendors to form a relationship, and run policies on my behalf that control those interactions.

Gaining Control

I'm very bullish on UMA and its potential to impact how we interact with various Web sites and apps. As the use of APIs grows there will be more and more opportunity to mix and mash them into new products and services. UMA is in a good position to ensure that such efforts don't die from user fatigue trying to keep track of it all or, worse, fear that they're losing control of their personal data.