UMA and OAuth 2 - First Impressions

I recently attended a briefing by Eve Maler, chair of the UMA Workgroup. As usual, Eve had lots of info to share, and I'd like to pass it on.

First, for those of you who don't know, OAuth 2.0, is a protocol designed to allow people to authorize one web service to access the resources of another web service. For example, allowing a photo printing service to access photos on Flickr.

UMA takes the concept of OAuth a step further and places the authorization server to a third party that works on behalf of an individual. By doing this, UMA take authorization from a resource perspective, and turns it into a consent server for users. That's pretty cool. So far, we've not had a good inter-site model for handling consent.

Where in the typical OAuth 2 deployment, user authorization and resource owner authorization are combined, UMA instead separates the processing of a user's consent, from authorizing access by the resource owner (e.g. Flickr).

Aside from the benefits Eve describes, here are a couple more things I like about the UMA proposal.

1. UMA recognizes that user information exists in many places on the Internet, and not just at a single IDP/OPs etc.
2. It supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.
3. It's a great way to separate the issue of user consent away from the resource owner's access control policy.
4. It becomes possible to handle consent when individuals are offline

The only downside I can see at the moment, is that the UMA Authorization server would get to know a lot about its users. What type of organizations would/could successfully offer UMA consent services? Any organization attempting this would have to have a strong privacy brand indeed. Monetizing private information would be a tough sell. Yet would users pay for the service? Anyway, not to worry, I'm sure someone will figure this out soon, if not already.

Will this be useful to the enterprise community? As with OAuth, I think so. This is an evolving space to watch.

Dave Kearns Suggests "World Wide Directory Service"

In his most recent column, Dave Kearns comments on IGF and how it could be used with virtual directories to form a world wide directory service.

This is a very interesting thought, but Mark Wilcox and I agree, a universal directory service operated or controlled by a single vendor isn't the right way to solve federated provisioning. For one thing, LDAP isn't the only requirement. Today's techniques for exchanging identity information involve many methods, and many modes (browser-based and backend-based). Any solution has to handle multiple identity protocols and should have no central point of control or storage. The implementation should not be owned by one vendor, it should be open, available for anyone to adopt and use. Rather than anything that approaches vendor lock-in, the solution has to be adjustable - preferably on-the-fly. The solution should be configurable and policy driven so that multiple technologies and providers can be used.

The need to link separate identity repositories around the world reminds me of the early days of enterprise networks. We used to talk about Ethernet networks, Token Ring, or even AppleTalk networks. These were standalone networks that tended to be isolated and self-sufficient with no concept of outside connectivity. Connections between networks were rare and expensive to implement. In part because the media (type of wire) for the network meant new protocols to handle communication. The TCP/IP "stack" came along and abstracted issues of network media and inter-network routing into layers. Everything changed. The Internet itself was born.

Applications today are at a similar crossroads. If they use identity services, the services are isolated to a single enterprise directory service. The problem? We as humans cross organization boundaries all the time. Applications are unable to expoit the power of the "Internet" when it comes to identity services. In the same way as TCP/IP solved media and inter-network challenges, applications need some way to handle the different protocols used in different enterprise networks. Most importantly, if we start networking identity information, applications and the enterprises that use them need a way to be able to respect privacy and ensure that the information being transferred is appropriate and secure.

What is needed is a multi-protocol identity networking "stack" that developers and service providers can use to interconnect systems. Instead of solving media and networking issues, this stack needs to solve identity mapping, routing, and protocol conversion. While IGF was originally specified for Identity Goverance, it turns out Dave Kearns is right, the IGF specifications may be an important part of the solution. More on that next time...

IGF Demonstration at Catalyst

Burton Group's Catalyst Conference is coming up.

If you are coming to Catalyst, remember to stop by the Oracle hospitality suite on Wednesday and look for the OpenLiberty IGF demonstration. I'm excited to say that we are getting to the point where we can show how IGF will work in practice. I'll be there talking about the open source openLiberty IGF project and demoing how the IGF Attribute Service API works.

For those who have been following the Identity Bus discussion, you should also check out the demo. The Attribute Service API definitely shows off a lot of the desired requirements that the bloggers have been talking about.

See you there!

IGF Attribute Services API Demo

I've been meaning to create a demo showing what it might be like for a developer to write applications that access identity information using the new CARML-enabled Attribute Services API. Accordingly I've put together this brief 10 minute video that demos how easy it is to write a JSP script to access identity information through a declarative API without having to worry about protocols, vendors, or deployment environments - the Identity Bus/Metaverse/Network just deals with the application's requirements based on configuration and policy and the application benefits!

This video just shows the developer's experience and why I think developers might start to get excited. Yes, the API is privacy enhancing and all that stuff, but the reality is, any new API has to be easy, powerful, and open (as in Apache 2 License in this case) or developers just aren't going to care. Jeff, I hope this answers some of your important concerns!

The video does not cover how the API does its work, nor how is the deployment managed and configured. However, if you are planning on attending the Burton Group Catalyst Conference, please be sure to stop by the booth and I'll give you a walk thru! I'll try and post more video's of IGF in action as time permits!

I hope this video shows at least an initial concept that represents the kind of vision that Kim Cameron, Dale Olds, Jackson Shaw, Dave Kearns and many others have been talking about. I don't think we are there yet...for that, we're gonna need your input! Check out the openLiberty project today!

[Note: Oops!! I just saw the rendering that YouTube did of my video. With the downscaling the screen shots became incredibly blurry. I'm going to play around and see if I can post this video in a way that is clearer.]

Identity Bus Discussion at European Identity Conference

Felix Gaehtgens leads an interesting round-table discussion on the "Identity Bus" and the need for a higher-level interface to identity with Dave Kearns, Kim Cameron, Jackson Shaw, and Dale Olds.

Felix...sorry I couldn't make it. I wish I could have been there!

Kim Cameron On The New Generation of Metadirectory

As you may know, there has been an ongoing discussion on what does the next generation of meta-directory look like. Kim Cameron's latest post elaborates on what he thinks is needed for the next generation of "metadirectory".

• By “next generation application” I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP.
• Developers and users need places they can go to query for “core attributes”. They must be able to use those attributes to “locate” object metadata. Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
• Applications need to be able to register the information fields they can serve up.

These are actually some of the key reasons I have been advocating for a new approach to developing identity services APIs for developers. We are actually very close in our thinking. Here are my thoughts:

• There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
• Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of "authoritativeness". Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn't authoritative over an attribute, it probably shouldn't be storing or managing that attribute. Instead, this "non-core" attribute should be obtained from the "identity network" (or metaverse as Kim calls it). An application's "core" data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  
• Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application's requirements.
  

What I have just described was actually part of the original inspiration behind CARML(Client Attributes Requirements Markup Language) put forward by Oracle that the Liberty Alliance is working on now. It was our belief that in order to enable applications to connect to diverse identity service infrastructures, something like CARML was needed to make the identity network both possible, adaptive, and intelligent.

But, while CARML was cool in itself, the business benefit to CARML was that knowing how an application consumes and uses identity data would not only help the identity network but it would also greatly improve the ability of auditors to perform privacy impact assessments.

We've recently begun an open source project at OpenLiberty called the IGF Attribute Services API that does exactly what Kim is talking about (by the way, I'm looking for nominations for a cool project name - let me know your thoughts). The Attribute Services API is still in early development stages - we are only at milestone 0.3. But that said, now is a great time for broader input. I think we are beginning to show that a fully de-coupled API that meets the requirements above is possible and dramatically easier to use and yet at the same time, much more privacy centric in its approach.

The key to all of this is to get as many applications as possible in the future to support CARML as a standard form of declaration. CARML makes it possible for identity infrastructure product vendors and service providers to build the identity network or next generation of metadirectory as described by Kim.