Last week, on behalf of the OAuth community, Eve Maler accepted an award for Best new or improved standard at the European Identity Conference 2009 (EIC), in Munich:

The European Identity Award for the category “Best new or improved standard” went to the Aristotle Project for ArisID, an important enhancement of IGF (Identity Governance Frameworks) and CARML, which enhances user-friendliness of these important standards for IAM and GRC. This particular innovation had been promoted and supported by Oracle. The standardization initiative OAuth (Open Authentication) receives an award for their streamlined approach for authentication standardization, which finds a lot of market interest. The last award in this category goes to the Information Card Foundation (ICF) for standardizing the important approach of Information Cards for future identity management.

As Eve happened to be at the conference, she received authorization on behalf of community to accept the award. We haven’t quite figured out what we’ll do with it (being that we’re a virtual, placeless entity!) but we appreciate being recognized all the same!

Specifications are tricky creatures. On their own, they are only copyrightable. But on their own they are also not very interesting. Their value is in their implementations, and those are subject to patents. If you have been following the tech world over the past couple of year, you know that patents can be very risky to developers. The problem is that in order to implement specifications, the developer usually has to write code that uses some existing patents. It is practically impossible to know which patents are involved, but at a minimum, the developers need to know that the people who wrote the specification are not going to sue them.

Over the past 8 months we have been working to obtain the necessary protections for the community, to be able to freely implement the OAuth Core 1.0 specification without any fear of being sued by any of the people involved (or their employers). Unlike specifications done in standard bodies where Intellectual Property Rights (IPR) are established ahead of time and set the scope and terms of the work, community specifications start with ideas and goodwill. This is a fundamental difference and a requirement for future community work. The need for the Open Web Foundation grew out of the frustration of communities like OAuth and OpenID having to go through hell to obtain these legal protections. In the next few months, the Open Web Foundation will offer tools and help communities avoid this painful process and focus on writing good specifications, not legal contracts.

Some of you will notice the new addition to the OAuth specification – the License section! A short paragraph detailing the licensing terms of the specification and providing links to the legal agreements. That short addition took hundred of hours and the dedication of many individuals and companies. Guaranteeing the open availability of this work is critical for small and large companies alike. Not everyone cares about this the same way and there are already implementations of OAuth out there. IPR risk is something very specific to each company and its culture, but this effort will help provide equal access to this important building block. It is not absolute protection – there is no such thing – but it is pretty good!

The community owes Eran, Gabe Wachob, DeWitt Clinton, David Recordon, Larry Halff, and Shreyas Doshi a great debt of gratitude for their hard work ensuring that the future of OAuth remains open and unencumbered.

Jeff Atwood brought up a problem that we’ve known about for quite awhile, have spent time documenting and working on and are finally on the verge of solving.

It’s important to highlight the seriousness and pervasiveness of this problem, and the degree to which people are still unaware that this pattern is a problem and even worse, that there are now ready solutions to make the process of getting access to your friends and contacts on third party sites that don’t require you to hand over your credentials. Once we standardize on a basic contact schema, it will only require adoption and implementation to obviate this insecure practice.

Eran just announced the second draft of OAuth Discovery, the first implementation of the XRDS-Simple specification that I mentioned here just over a week ago.

What’s significant about this announcement, as Eran points out, is that the new draft is already implemented and deployed by FireEagle (a Yahoo! Brickhouse service), Ma.gnolia, and Get Satisfaction — three leaders in the OAuth community. On the development tools front, Mediamatic will release initial support for discovery early next week with full support due early May in their OAuth PHP library.

This draft is a complete rewrite of the first draft released several months ago and, in the spirit of OAuth, greatly simplifies the concepts and presentation of the protocol, and incorporates a great many of the clarifications provided by the OAuth and XRI communities.

OAuth Discovery, simply, is an extensible, machine-readable format for identifying OAuth-protected resources and service endpoints. Take a look at the provided example or Ma.gnolia’s actual discovery profile to get an idea for what these documents look like.

Over time, the goal is to automate the pairing of unacquainted web services, by being able to first identify the location of services on the web and second to discover the authentication requirements for accessing such services. Coupled with XRDS-Simple, you can further specify the types of data available from given services, and to begin to describe the methods you would use to access that data.

To provide a more complete conceptual model, imagine that you run a social network, and in this network, members have collections of bookmarks. Your service provides a way to either upload bookmarks directly or to subscribe to someone’s existing bookmarks stored at, say, services like Delicious or Ma.gnolia. Now say that you also encourage new members to sign in with an OpenID identity. From that identity, you may be able to discover an XRDS-Simple profile that points to an existing social bookmarking account, allowing you to attempt to import those bookmarks immediately. If, however, those bookmarks require authorization, and the authorization protocol happens to be OAuth, you should be able to automate the appropriate authorization requests to the user because the service supports OAuth Discovery.

In contrast, to achieve the same flow today, you must manually provide the names of accounts and services that you use individually, and then hope that the new service supports the remote protocols of your pre-existing services. With XRDS-Simple and OAuth Discovery, much of this work is automatically handled for you, letting you focus more on what you want to share, and less on where your data is stored, and increasingly allowing data to automatically flow between systems, should you decide to provide them authorization to do so on your behalf.

If you’re interest in learning more about OAuth Discovery, the best place to go is the OAuth Extensions group. Since OAuth Discovery also borrows heavily on XRDS-Simple, you might also want to check out that specification and discuss it in the related group.

There actually isn’t too much to report as Google is using AuthSub for the API at the moment, but, according to ReadWriteWeb, Google’s Kevin Marks said, At the moment, it is delegated to the containers. Clearly this needs to work better. We are looking at OAuth.

As Google (and others) has been involved in the development of the OAuth spec, we’d love to see Google and other service providers consider using OAuth for OpenSocial applications (and efforts are already underway to combine them); it was designed with this kind of widespread use in mind and with these kind of applications at their center. After all the work that’s gone into OAuth so far, from various industry leaders and grassroots developers, it’s the perfect timing, with Final Draft 5 out, to put OAuth into production.

Memo to OAuth Service Providers: think of your consumers as your partners, and not just "users".

• Understand that many of the consumer applications of your service are driving users to your site,
  and in the world of composable services, your consumer application developers
  will often have choice. Choice means power. Recognize.
• Keep the channels of communication open with developers of consumers of your service. Use blogs, email lists, IRC channels, and show up at community events that are relevant to your service (barcamps, superhappydevhouse, etc).
• Be transparent about API changes – try to schedule changes ahead of time, try to keep changes limited to a regular scheduled time, be prepared to rollback changes, and be especially available immediately after API changes.
• Think like a service provider and be concerned about security, availability and uptime, even if nobody is directly complaining – remember, your service availability may impact the perceived quality of the services offered by consumer applications.
• Be transparent about outages – you will have more credibility with your consumers (see above about choice).
• Be proactive about supporting consumer applications – know which consumer applications are accessing your service – you never know who your friends might be. I suspect OAuth will be a great channel for business development!

Service providers who do this well: Linden Labs (Second Life), Pair Networks.

If you’re interested in this topic, I’ll be at SuperHappyDevHouse 20 this weekend, and at a OAuth implementers meetup at SHDH20.