The OAuth 2.0 draft specification is out there. The efforts of the group working on the specification are paying off in the form of an IETF working group submission. One thing is clear, there is a natural tension in following the processes of IETF and the hyper-innovation cycle of web standards that are now powered by the growth of social media.

In this world, keeping up with all the work in the community itself is a feat in itself. As proven recently, even aligning the naming of standards in our small community (xAuth, XAuth) proves challenging enough. With that said, we’ll share we what we’ve learned about this version and what work has been incorporated into it.

Sponsor

For those coming up to speed on the issues surrounding OAuth 2.0, here is a brief summary of the state of the union:

The OAuth Working Group in IETF generated a first draft of OAuth 2.0. This group that is credited with this document consists of active leaders of both the Twitter API team as well as Facebook community standards team. A robust number of daily discussions are happening in the working group hosted at IETF include topics such as the default use of JSON that show the opportunity and challenge of growing the standard from a web-based to a broader set of devices and scenarios.

One of the stated goals of the IETF OAuth working group is to maintain backwards compatibility with OAuth 1.0. From our sampling of the depth of change in scope and conceptualization of the standard, this may be a big deal for the group, especially if key members decide to legacy their support for the first versions.

As part of the evolution of OAuth, there is the case of the OAuth WRAP Google Group. This group has forged ahead to develop profiles for scenarios seen as extensions to the profile OAuth 1.0A. This includes new ways to gain tokens bringing the use cases of Javascript or RIA applications. WRAP also redefines the dependency on SSL and provides a simpler way to get started using tools easily accessible to the web resource. With some changes noted, this work has been brought forward in the OAuth 2.0 public draft.

David Recordon, a chief thought leader in the open web (also employee at Facebook) recently offered this summary “What’s going on with OAuth?” to help align the understanding of the evolution of the standard.

Here we show one of the better known descriptions of the OAuth flow as provided by Yahoo. The annotations show a few of the areas that are under consideration for changes in OAuth 2.0 and/or in the work done in the OAuth WRAP group.

Last week, at Twitter’s Chirp ‘10 the Twitter API team gave this presentation, “Too many secrets, but never enough: OAuth at Twitter“. This document contains overview of the basic process of Twitter, commitment to the movement to OAuth 2.0, and discussion of Twitter’s xAuth and OAuth Echos projects.

Twitter Likes to Optimize

Twitter is deeply intertwined with the inception and direction of OAuth. The company is both involved in the specifications but also is a lightening rod for discussion in the development community. In the Twitter blogs and developer groups, OAuth is being considered deeply in the trade-offs in implementation, design, and risk in the Twitter ecosystem.

A few areas under discussion is how to remove the re-direction from the process, and also how to keep a running log of all account client accesses available to the user as a way to make sure users are aware and signaling proper account use.

The Twitter API team has been willing to make change happen in the community by deprecating legacy processes, such as basic auth. With the changes coming in OAuth 2.0 the company may be in the best position to bootstrap developer adoption of the new standards.

In this way, OAuth 2.0 need to adapt to the speed and need of the Twitter use cases, to avoid becoming like XML. XML is a good thing, of course, but when push comes to shove, JSON is lighter weight and more compact. This is helping it become the preference for data attribute exchange in APIs like Twitters that support OAuth.

With the rise of the social ecosystem as the hub for authorization, it is becoming clear that the IETF efforts need Twitter as much as Twitter needs the IETF. This seems like a good balance that will guide use cases along the way to practical standards formalization.

There are a lot of questions out there about OAuth 2.0. Top of mind is whether this technology release will see the effective join of Twitter, Facebook, and Google? Or, will the practical matters of business and strategy keep the standards intact, and the implementations as islands?

What is your prediction for OAuth 2.0 and web resource authorization?

Discuss

The OAuth 2.0 draft specification is out there. The efforts the group working on the specification are paying off in the form of an IETF working group submission. One thing that is clear is that there is a natural tension in following the processes of IETF and the hyper-innovation cycle of web standards that are now powered by the growth of social media.

In this world, keeping up with all the work in the community itself is feat by itself. As proven recently, even aligning the naming of standards in our small community (xAuth, XAuth) proves challenging enough. With that said, we’ll share we what we’ve learned about this version and what work has been incorporated in it.

Sponsor

For those coming up to speed on the issues surrounding OAuth 2.0, here is a brief summary of the state of the union:

The OAuth Working Group in IETF generated a first draft of OAuth 2.0. This group that is credited with this document consists of active leaders of both the Twitter API team as well as Facebook community standards team. A robust number of daily discussions are happening in the working group hosted at IETF include topics such as the default use of JSON that show the opportunity and challenge of growing the standard from a web-based to a broader set of devices and scenarios.

One of the stated goals of the IETF OAuth working group is to maintain backwards compatibility with OAuth 1.0. From our sampling of the depth of change in scope and conceptualization of the standard, this may be a big deal for the group, especially if key members decide to legacy their support for the first versions.

As part of the evolution of OAuth, there is the case of the OAuth WRAP Google Group. This group has forged ahead to develop profiles for scenarios seen as extensions to the profile OAuth 1.0A. This includes new ways to gain tokens bringing the use cases of Javascript or RIA applications. WRAP also redefines the dependency on SSL and provides a simpler way to get started using tools easily accessible to the web resource. With some changes noted, this work has been brought forward in the OAuth 2.0 public draft.

David Recordon, a chief thought leader in the open web (also employee at Facebook) recently offered this summary “What’s going on with OAuth?” to help align the understanding of the evolution of the standard.

Here we show one of the better known descriptions of the OAuth flow as provided by Yahoo. The annotations show a few of the areas that are under consideration for changes in OAuth 2.0 and/or in the work done in the OAuth WRAP group.

Last week, at Twitter’s Chirp ‘10 the Twitter API team gave this presentation, “Too many secrets, but never enough: OAuth at Twitter“. This document contains overview of the basic process of Twitter, commitment to the movement to OAuth 2.0, and discussion of Twitter’s xAuth and OAuth Echos projects.

Twitter Likes to Optimize

Twitter is deeply intertwined with the inception and direction of OAuth. The company is both involved in the specifications but also is a lightening rod for discussion in the development community. In the Twitter blogs and developer groups, OAuth is being considered deeply in the trade-offs in implementation, design, and risk in the Twitter ecosystem.

A few areas under discussion is how to remove the re-direction from the process, and also how to keep a running log of all account client accesses available to the user as a way to make sure users are aware and signaling proper account use.

The Twitter API team has been willing to make change happen in the community by deprecating legacy processes, such as basic auth. With the changes coming in OAuth 2.0 the company may be in the best position to bootstrap developer adoption of the new standards.

In this way, OAuth 2.0 need to adapt to the speed and need of the Twitter use cases, to avoid becoming like XML. XML is a good thing, of course, but when push comes to shove, JSON is lighter weight and more compact. This is helping it become the preference for data attribute exchange in APIs like Twitters that support OAuth.

With the rise of the social ecosystem as the hub for authorization, it is becoming clear that the IETF efforts need Twitter as much as Twitter needs the IETF. This seems like a good balance that will guide use cases along the way to practical standards formalization.

There are a lot of questions out there about OAuth 2.0. Top of mind is whether this technology release will see the effective join of Twitter, Facebook, and Google? Or, will the practical matters of business and strategy keep the standards intact, and the implementations as islands?

What is your prediction for OAuth 2.0 and web resource authorization?

Discuss

National Public Radio first began offering its content via API nearly two years ago now and business, to say the least, has been booming.

According to a blog post today by NPR Director of Application Development Daniel Jacobson, the API delivered more than 1.1 billion stories last month, and almost 5 billion since tracking began six months ago.

Sponsor

First, Jacobson shows the number of API requests made over the past six months, which he explains does not translate directly to the number of stories delivered.

According to Jacobson, “The big jump in total API requests from July to August are due to the launch of many new products in July. Among them are the new NPR.org, the NPR.org Flash Player, the NPR News iPhone app, WBUR’s new web site, and Minnesota Public Radio’s new site.”

Next, we see the number of stories delivered, which turns out to be an equally impressive chart.

NPR’s API allows outside parties to have access to audio content dating back to 1995, consisting of more than 250,000 stories in more than 5,000 different aggregations. The results are returned in a number of formats, from RSS, MediaRSS, JSON and Atom to NPRML, a specialized format that accounts for 86% of content distribution. Jacobson notes, however, that an overwhelming majority of content delivered by NPR’s API is being sent to affiliated sites and stations.

While some media companies, such as News Corp, attempt to block their content from distribution, the NPR API seems to be making access to its content widespread. Jacobson includes a slideshow at the end of his post that shows just how many places and ways NPR content is being accessed as a result of its API.

To use NPR content via API, all you need to do is register with NPR and agree to its terms. The company says that “we want you to use, enjoy and share the journalism and programming produced by NPR and participating NPR member stations, but it is also important to respect the rights and integrity of the work and of the dedicated people who created it.”

Discuss