Since my talk last year at Reboot on Agile Banking the Agile Banking Mailing List has been quite active with lots of different ideas. One of the most important yet also simple products of the list has been OpenTransact which I now realize I haven’t even mentioned on my blog.

OpenTransact aims to be the worlds simplest technical standard for transferring some sort of value between 2 accounts. We wanted it to be so simple that there wouldn’t be a good technical excuse for not implementing it and also make it extremely simple to build all sorts of new value added services on top of it. You can find out more at the OpenTransact site and I will post a detailed article about it tomorrow.

In this article I will focus on what we’ve got. Current payment standards and bank business processes are incredibly complex and I don’t pretend to understand all of it, but I will try to present a much simplified version of what goes on.

What is wrong with existing Payment Standards?

Complex messages

The big issue with most of them is that they are ancient (SWIFT the standard banks use to transfer funds internationally dates back to the mid 70s). Most of them are designed for ancient technology like mainframes with batch processing as well as ancient business practices such as delayed settlement and bank opening hours.

Most of these standards are message based and extremely complex.

SWIFT has 25 standard data elements and 79 types of messages with strange names like MT542. People make good money specializing in specific message types. You often see programmer jobs in the financial industry calling for 3 years of experience in eg. MT530.

ISO 8583 which is used for handling most payment card transactions dates from 1987 is a little better in that at least it does expect to be able to send one or two small messages online, but still most of the heavy lifting is done after the fact in the settlement phase.

Most countries have their own electronic banking clearing systems with their own set of standards and procedures. The largest US clearing system ACH won’t even let you at their online rules website without buying a $79 book.

Security nightmares

Any non cash financial transaction consists of one or more entries known as book entries into various companies databases. By definition any act of creating a financial transaction is delegated by you to someone else. Whenever your transaction involves another bank your original delegation gets delegated onwards to x number of other institutions. Unfortunately the transactions are often unauthenticated. Whether you are sitting in a bank office ordering a wire transfer or handing a waiter your credit card you are delegating authority to transfer funds out of your account. This is why a check says “Pay to the order of…”.

Card payments do support some level authentication from pin to signing via an onboard smart card. But they aren’t used when performing an internet payment. This is obviously where much of the fraud goes on. Credit Card or ACH fraud essentially boils down to convincing (delegating) someone to transfer funds from the victims account.

Since you can’t satisfactorily secure the payment message most of these standards come with complex reconciliation standards that make up most of their complexity and even larger and more complex rule books. These rules are what allow you to deny a transaction when you get your statement a month later after the fact.

Enter PayPal

PayPal’s original Website Payment API while not a standard was a big step up over the actual standards in that it was born of the web. Web 1.0 yes but still the web. So rather than using REST to hide some of the complexity it uses a single URL with lots of different fields including optional non payment fields such as address and shipping details.

A big issue that PayPal had was that they still had to interface with the traditional banking world with their settlement times and insecure payments. To make it economical for them they need to use ACH and similar slow low cost national payment networks guaranteed by credit cards if these don’t go through. This is where much of the complexity of dealing with their Instant Payment Notification comes from.

Most of PayPal’s competitors use similar API’s to PayPal’s, but there hasn’t been any real standardization on it yet.

Their new Adaptive Payment API is much clearer. Yet still fairly complex for a new developer faced with it. And no it’s still not REST.

Why is it like this?

Closing Time

There are many reasons why banking related standards are complex. Most of them are historical. For example banks still operate 5 days a week with close of business at some time like 6pm decided many decades ago by gentlemen in top hats. Of course they do work 24 hours but all their processes are still based on this pre online world.

This means there is still a lot of batch processing going on in that last hour before closing. Most banks have a cutoff time a couple hours earlier than their official closing time to give them time to batch up and reconcile the days business. This is why you have to rush to the bank with your checks before 3pm on a Friday or it won’t get credited until Monday evening.

Settlement

Settlement is another important issue that all of these ancient standards have to deal with. Once you’ve bought that dry martini in the bar after work with your debit card, the money doesn’t actually leave your account yet. Your bank basically puts a hold on your money first. Then over the next couple of days they settle it through a network of banks and institutions depending on the country. Most of the settlement processes is done through batch processes once a day, the more step between your bank and the bars bank the longer settlement takes.

Most of these settlement (clearing) times are standardized by rules set out by central banks or banking associations. The holy grail for many of these systems is to reach what is known a T+0 clearing, which is fancy banker speak for instant clearing. It will take a long time for this to happen in most large economies like the US as there isn’t really a demand for it from anyone except consumers and small businesses.

Conclusion

Any new standard or API that attempts to deal with the existing banking standard is very difficult to simplify. You need to account for each countries settlement and fraud prevention rules. SWIFT was updated to a fancy smancy new XML standard, which didn’t do anything to simplify it besides making it easier to parse.

Any kind of innovation in this needs to be designed for an online world with 7 days, 24 hours and clear simple standards that only aim to solve a simple need. We have had this magic new technology now called HTTP thats been here for close to 20 years now and it’s been kind of successful. OpenTransact is only a very thin layer on top of HTTP and uses OAuth for its authentication, I think it is going to be big. But I will write more on that in my next post.

One of the great new standards made possible by OAuth is PortableContacts. Joseph Smarr from Plaxo is the main force behind it together with Chris Messina and others.

Portable Contacts as the name suggests is a standard for allowing one application access to your contact data on another application. The standard is a nice example of a very clean API which supports both JSON and XML.

I was looking around and I couldn’t find a Ruby library for it, so I wrote this simple Portable Contacts Ruby Gem to allow me and others to use it.

It requires OAuth and the Ruby OAuth Gem. If you need to use it with a Rails application use the OAuth Plugin if using straight Ruby use the Ruby Gem. All you need is an AccessToken object and a Portable Contacts URL to get started.

@access_token = ... # instantiate access token
@client = PortableContacts::Client.new "http://www-opensocial.googleusercontent.com/api/people", @access_token

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

If you are using the plugin it is very easy to get started accessing Google.

Just install it and configure it. Once you have a GoogleToken for your user:

@google_token=GoogleToken.find_by_user_id @user.id
@client = @google_token.portable_contacts

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

As this is the very first version there are likely to be issues, please do submit patches. I would also love to include a PlaxoToken etc for the OAuth Plugin if someone wants to submit one.

Plans

Eventually there will be some sort of auto discovery so you don’t need to provide a Portable Contacts url.

I would also like to add a server component to the gem, making it easy for you to provide portable contacts for your own application.

Yahoo implemented OAuth sometime last year. So now you use the same OAuth libraries that you use to connect to Google, Twitter, MySpace etc to access your users Yahoo address books. This is the Yahoo OAuth Documentation.

The only problem is that Yahoo quietly pushed through an extension to OAuth called the OAuth Session Extension. This was all done publicly but it involves some major changes to OAuth token management, which is the exact thing that has been hardest for people to understand about OAuth in the first place.

Right now I’m feeling a bit like Arthur Dent in the Hitchhikers Guide to the Galaxy lying in front of the bulldozer trying to demolish my home:

“But Mr. Dent, the plans have been available in the local planning office for the last nine months.”

“Oh yes, well, as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything.”

The thing is Authentication standards are hard, they are by necessity complex. Therefore it is vital that they are predictable. It isn’t the job of an developer trying to connect to their users Yahoo address book to understand all the different complexities of the standard. This is the job of the library writers.

I think we have done a great job in the Ruby community with the OAuth libraries. The “Ruby Gem” of which I was one of the co-authors of does a great job of handling the complexity, but still caused several problems with new users as it still required you to understand the OAuth flow. My new OAuth Consumer Rails Plugin attempts to hide that to make it extremely easy for developers to write applications that access Twitter, Google, FireEagle etc.

The Token Refresh Step

While I hadn’t personally been looking at the special requirements for communicating with Yahoo as I haven’t had the need until now. I had noticed the large amounts of problems people have had with Yahoo. I knew there were a couple of extra fields to pass along throughout the flow, which isn’t a problem. I also noticed that the tokens were quite large at around 800 bytes. Those are all things you can work around as they don’t change the flow. The big problem is the completely new Token Refresh step.

Basically when you get an AccessToken from Yahoo it is only valid for an hour. So you need to refresh it by requesting a new access token before attempting to use it again. This means that we as consumers of Yahoo web services need to monitor expiration of Yahoo tokens, create an additional HTTP requests before we can connect for whatever it is we are using it for.

No, this is not insurmountable, they just add a lot more complexity to our code.

We are asked to pay for Yahoo’s scalability issues

However when you dig down and find out the reason for this it is quite interesting. Apparently the reason for this is due to Yahoo’s security architecture.

Allen Tom from Yahoo writes in the original proposition#

Very large service providers may have a distributed architecture in
which the service endpoints are able to cryptographically verify the
authentication credentials without calling back to a central database.
Permission revocation is implemented by issuing consumers a relatively
short lived session credential, and requiring consumers to
periodically obtain new session credentials from a central
authorization service. The authentication service performs the
necessary checks before issuing new session credentials.

Although it is technically possible for SPs to build an OAuth
translation layer on top of their existing services, the cost may
involve additional latency and decreased reliability if OAuth
verification required a query to a database located in a very distant
datacenter.

This is also mentioned in a tiny paragraph at the end of the OAuth Session Extension Spec

Allowing Access Tokens to be revoked before they expire requires Service Providers to perform a database lookup before serving a Protected Resource. For performance reasons, Service Providers may want to issue Access Tokens that can be validated without a database lookup, provided that the Access Token lifetime is less than then the Service Provider’s allowable latency for Access Token revocation.

So Yahoo proposed this for all intents and purposes to avoid a database call on every request. I can understand they want to avoid this, but there are lots of other solutions.

This all explains the Yahoo token size. Basically Yahoo’s token contains expiry information, probably a user id and some sort of consumer id. This is all encrypted and signed similar to the Rails’ cookie based sessions. This is very clever and I can appreciate the design. This allows the various servers in Yahoo’s cloud to verify OAuth tokens without accessing a central OAuth token database.

The expiry and refresh section is so users can revoke an applications token. By the time my application attempts to refresh the token from Yahoo’s token servers my user might have removed the permissions and the token refresh is declined.

A solution to Yahoo’s problem

Rather than us the developers having to refresh the token, I think it would make a lot more sense to leave expiry out of the token completely. The following would happen within Yahoo and be completely hidden from external application:

1. Application requests contact info from Yahoo
2. Yahoo’s Contacts API server looks in local token cache for applications token
3. Token is not found in cache
4. Contacts API server asks internal OAuth server to verify Token and returns secret
5. Token and token secret is stored in cache with 1 hour expiry

This allows Yahoo to manage their internal OAuth token expiry in a very scalable way without adding any additional complexity for external developers. And yes Yahoo I will happily sign an IPR for you if you need it to implement this.

Just say no to extra vendor tax

What Yahoo’s OAuth implementation is, is a de facto tax on people developing towards their API’s. It adds additional overhead and complexity to libraries, extra unnecessary http requests for developers and breaks what is supposed to be a standard.

I have decided to stand firm and not add support for Yahoo to the OAuth Plugin. I started work on it but I have removed it from the current release and won’t add it back until they follow the standard OAuth flow. I encourage other library authors to do the same.

Why is this so important

OAuth was designed as lower level modern authentication standard that other higher level applications can be built upon. An extension on top of it is the OAuth discovery proposal which in theory would allow you to connect to any provider by just giving it a single top level URL.

So lets say I wanted to connect to Yahoo. I could just do something like:

@yahoo = OAuth::Consumer.new :site=>"http://yahoo.com"

Everything afterwards would be automatic. No specifying of request token urls, authorization urls etc.

What makes this even more interesting is when you start adding higher level API’s on top of OAuth, such as Portable Contacts. This would allow you with a single library with no extra code access your users address book, whether it is on Yahoo, Google, Plaxo or even your own personal address book server. Having a straightforward discoverable protocol without extra overhead makes it simple for developers to access. It removes all the proprietary code exceptions we have to write today.

Having proprietary extensions on something as fundamental as the OAuth token request cycle breaks the beauty and simplicity of PortableContacts and other future standards.

Should standards be dictated by large corporations?

My point about all of this is that I don’t think it is right that large companies try and push through changes to community created standards solely because it will make their life a little bit easier. OAuth came out of small startups and individuals who saw a common problem and wanted to create a solution. We should not just blindly accept every suggestion that comes out of large companies just so we can announce with much excitement that we have the support of Google, Yahoo or Microsoft. I think it’s great that they join in the process, but we should not bend our principles, just for the sake of them joining.

The debate on the mailing list

I have been debating this on the OAuth mailing list and while my initial tone was definitely negative, it was never targeted at any individuals. Unfortunately the discussion has now become more of a personal fight, which I don’t think is particularly useful.

While this particular discussion is about Yahoo I would be equally disturbed by it if any other major provider tried to do the same thing. Yahoo is famous in OAuth circles for their corporate culture and infrastructure leaking into the standards as wast last seen during the OAuth IPR debate last year.

Yahoo has done great work in a whole lot of instances. FireEagle in particular is still one of the best OAuth implementations out there. I just wish they had done a better job of thinking through their corporate OAuth strategy.

Yahoo implemented OAuth sometime last year. So now you use the same OAuth libraries that you use to connect to Google, Twitter, MySpace etc to access your users Yahoo address books. This is the Yahoo OAuth Documentation.

The only problem is that Yahoo quietly pushed through an extension to OAuth called the OAuth Session Extension. This was all done publicly but it involves some major changes to OAuth token management, which is the exact thing that has been hardest for people to understand about OAuth in the first place.

Right now I’m feeling a bit like Arthur Dent in the Hitchhikers Guide to the Galaxy lying in front of the bulldozer trying to demolish my home:

“But Mr. Dent, the plans have been available in the local planning office for the last nine months.”

“Oh yes, well, as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything.”

The thing is Authentication standards are hard, they are by necessity complex. Therefore it is vital that they are predictable. It isn’t the job of an developer trying to connect to their users Yahoo address book to understand all the different complexities of the standard. This is the job of the library writers.

I think we have done a great job in the Ruby community with the OAuth libraries. The “Ruby Gem” of which I was one of the co-authors of does a great job of handling the complexity, but still caused several problems with new users as it still required you to understand the OAuth flow. My new OAuth Consumer Rails Plugin attempts to hide that to make it extremely easy for developers to write applications that access Twitter, Google, FireEagle etc.

The Token Refresh Step

I had not been looking at the special requirements for communicating with Yahoo as I haven’t had the need until now. I had noticed the large amounts of problems people have had with Yahoo. I new there were a couple of extra fields to pass along throughout the flow, which isn’t a problem. I also noticed that the tokens were quite large at around 800 bytes. Those are all things you can work around as they don’t change the flow. The big problem is the completely new Token Refresh step.

Basically when you get an AccessToken from Yahoo it is only valid for an hour. So you need to refresh it by requesting a new access token before attempting to use it again. This means that we as consumers of Yahoo web services need to monitor expiration of Yahoo tokens, create an additional HTTP requests before we can connect for whatever it is we are using it for.

No, this is not insurmountable, they just add a lot more complexity to our code.

We are asked to pay for Yahoo’s scalability issues

However when you dig down and find out the reason for this it is quite interesting. Apparently the reason for this is due to Yahoo’s security architecture.

Allen Tom from Yahoo writes in the original proposition#

Very large service providers may have a distributed architecture in
which the service endpoints are able to cryptographically verify the
authentication credentials without calling back to a central database.
Permission revocation is implemented by issuing consumers a relatively
short lived session credential, and requiring consumers to
periodically obtain new session credentials from a central
authorization service. The authentication service performs the
necessary checks before issuing new session credentials.

Although it is technically possible for SPs to build an OAuth
translation layer on top of their existing services, the cost may
involve additional latency and decreased reliability if OAuth
verification required a query to a database located in a very distant
datacenter.

This is also mentioned in a tiny paragraph at the end of the OAuth Session Extension Spec

Allowing Access Tokens to be revoked before they expire requires Service Providers to perform a database lookup before serving a Protected Resource. For performance reasons, Service Providers may want to issue Access Tokens that can be validated without a database lookup, provided that the Access Token lifetime is less than then the Service Provider’s allowable latency for Access Token revocation.

So Yahoo proposed this for all intents and purposes to avoid a database call on every request. I can understand they want to avoid this, but there are lots of other solutions.

This all explains the Yahoo token size. Basically Yahoo’s token contains expiry information, probably a user id and some sort of consumer id. This is all encrypted and signed similar to the Rails’ cookie based sessions. This is very clever and I can appreciate the design. This allows the various servers in Yahoo’s cloud to verify OAuth tokens without accessing a central OAuth token database.

The expiry and refresh section is so users can revoke an applications token. By the time my application attempts to refresh the token from Yahoo’s token servers my user might have removed the permissions and the token refresh is declined.

A solution to Yahoo’s problem

Rather than us the developers having to refresh the token, I think it would make a lot more sense to leave expiry out of the token completely. The following would happen within Yahoo and be completely hidden from external application:

1. Application requests contact info from Yahoo
2. Yahoo’s Contacts API server looks in local token cache for applications token
3. Token is not found in cache
4. Contacts API server asks internal OAuth server to verify Token and returns secret
5. Token and token secret is stored in cache with 1 hour expiry

This allows Yahoo to manage their internal OAuth token expiry in a very scalable way without adding any additional complexity for external developers. And yes Yahoo I will happily sign an IPR for you if you need it to implement this.

Just say no to extra vendor tax

What Yahoo’s OAuth implementation is, is a de facto tax on people developing towards their API’s. It adds additional overhead and complexity to libraries, extra unnecessary http requests for developers and breaks what is supposed to be a standard.

I have decided to stand firm and not add support for Yahoo to the OAuth Plugin. I started work on it but I have removed it from the current release and won’t add it back until they follow the standard OAuth flow. I encourage other library authors to do the same.

Why is this so important

OAuth was designed as lower level modern authentication standard that other higher level applications can be built upon. An extension on top of it is the OAuth discovery proposal which in theory would allow you to connect to any provider by just giving it a single top level URL.

So lets say I wanted to connect to Yahoo. I could just do something like:

@yahoo = OAuth::Consumer.new :site=>"http://yahoo.com"

Everything afterwards would be automatic. No specifying of request token urls, authorization urls etc.

What makes this even more interesting is when you start adding higher level API’s on top of OAuth, such as Portable Contacts. This would allow you with a single library with no extra code access your users address book, whether it is on Yahoo, Google, Plaxo or even your own personal address book server. Having a straightforward discoverable protocol without extra overhead makes it simple for developers to access. It removes all the proprietary code exceptions we have to write today.

Having proprietary extensions on something as fundamental as the OAuth token request cycle breaks the beauty and simplicity of PortableContacts and other future standards.

Should standards be dictated by large corporations?

My point about all of this is that I don’t think it is right that large companies try and push through changes to community created standards solely because it will make their life a little bit easier. OAuth came out of small startups and individuals who saw a common problem and wanted to create a solution. We should not just blindly accept every suggestion that comes out of large companies just so we can announce with much excitement that we have the support of Google, Yahoo or Microsoft. I think it’s great that they join in the process, but we should not bend our principles, just for the sake of them joining.

The debate on the mailing list

I have been debating this on the OAuth mailing list and while my initial tone was definitely negative, it was never targeted at any individuals. Unfortunately the discussion has now become more of a personal fight, which I don’t think is particularly useful.

While this particular discussion is about Yahoo I would be equally disturbed by it if any other major provider tried to do the same thing. Yahoo is famous in OAuth circles for their corporate culture and infrastructure leaking into the standards as wast last seen during the OAuth IPR debate last year.

Yahoo has done great work in a whole lot of instances. FireEagle in particular is still one of the best OAuth implementations out there. I just wish they had done a better job of thinking through their corporate OAuth strategy.

Yahoo implemented OAuth sometime last year. So now you use the same OAuth libraries that you use to connect to Google, Twitter, MySpace etc to access your users Yahoo address books. This is the Yahoo OAuth Documentation.

The only problem is that Yahoo quietly pushed through an extension to OAuth called the OAuth Session Extension. This was all done publicly but it involves some major changes to OAuth token management, which is the exact thing that has been hardest for people to understand about OAuth in the first place.

Right now I’m feeling a bit like Arthur Dent in the Hitchhikers Guide to the Galaxy lying in front of the bulldozer trying to demolish my home:

“But Mr. Dent, the plans have been available in the local planning office for the last nine months.”

“Oh yes, well, as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything.”

The thing is Authentication standards are hard, they are by necessity complex. Therefore it is vital that they are predictable. It isn’t the job of an developer trying to connect to their users Yahoo address book to understand all the different complexities of the standard. This is the job of the library writers.

I think we have done a great job in the Ruby community with the OAuth libraries. The “Ruby Gem” of which I was one of the co-authors of does a great job of handling the complexity, but still caused several problems with new users as it still required you to understand the OAuth flow. My new OAuth Consumer Rails Plugin attempts to hide that to make it extremely easy for developers to write applications that access Twitter, Google, FireEagle etc.

The Token Refresh Step

I had not been looking at the special requirements for communicating with Yahoo as I haven’t had the need until now. I had noticed the large amounts of problems people have had with Yahoo. I new there were a couple of extra fields to pass along throughout the flow, which isn’t a problem. I also noticed that the tokens were quite large at around 800 bytes. Those are all things you can work around as they don’t change the flow. The big problem is the completely new Token Refresh step.

Basically when you get an AccessToken from Yahoo it is only valid for an hour. So you need to refresh it by requesting a new access token before attempting to use it again. This means that we as consumers of Yahoo web services need to monitor expiration of Yahoo tokens, create an additional HTTP requests before we can connect for whatever it is we are using it for.

No, this is not insurmountable, they just add a lot more complexity to our code.

We are asked to pay for Yahoo’s scalability issues

However when you dig down and find out the reason for this it is quite interesting. Apparently the reason for this is due to Yahoo’s security architecture.

Allen Tom from Yahoo writes in the original proposition#

Very large service providers may have a distributed architecture in
which the service endpoints are able to cryptographically verify the
authentication credentials without calling back to a central database.
Permission revocation is implemented by issuing consumers a relatively
short lived session credential, and requiring consumers to
periodically obtain new session credentials from a central
authorization service. The authentication service performs the
necessary checks before issuing new session credentials.

Although it is technically possible for SPs to build an OAuth
translation layer on top of their existing services, the cost may
involve additional latency and decreased reliability if OAuth
verification required a query to a database located in a very distant
datacenter.

This is also mentioned in a tiny paragraph at the end of the OAuth Session Extension Spec

Allowing Access Tokens to be revoked before they expire requires Service Providers to perform a database lookup before serving a Protected Resource. For performance reasons, Service Providers may want to issue Access Tokens that can be validated without a database lookup, provided that the Access Token lifetime is less than then the Service Provider’s allowable latency for Access Token revocation.

So Yahoo proposed this for all intents and purposes to avoid a database call on every request. I can understand they want to avoid this, but there are lots of other solutions.

This all explains the Yahoo token size. Basically Yahoo’s token contains expiry information, probably a user id and some sort of consumer id. This is all encrypted and signed similar to the Rails’ cookie based sessions. This is very clever and I can appreciate the design. This allows the various servers in Yahoo’s cloud to verify OAuth tokens without accessing a central OAuth token database.

The expiry and refresh section is so users can revoke an applications token. By the time my application attempts to refresh the token from Yahoo’s token servers my user might have removed the permissions and the token refresh is declined.

A solution to Yahoo’s problem

Rather than us the developers having to refresh the token, I think it would make a lot more sense to leave expiry out of the token completely. The following would happen within Yahoo and be completely hidden from external application:

1. Application requests contact info from Yahoo
2. Yahoo’s Contacts API server looks in local token cache for applications token
3. Token is not found in cache
4. Contacts API server asks internal OAuth server to verify Token and returns secret
5. Token and token secret is stored in cache with 1 hour expiry

This allows Yahoo to manage their internal OAuth token expiry in a very scalable way without adding any additional complexity for external developers. And yes Yahoo I will happily sign an IPR for you if you need it to implement this.

Just say no to extra vendor tax

What Yahoo’s OAuth implementation is, is a de facto tax on people developing towards their API’s. It adds additional overhead and complexity to libraries, extra unnecessary http requests for developers and breaks what is supposed to be a standard.

I have decided to stand firm and not add support for Yahoo to the OAuth Plugin. I started work on it but I have removed it from the current release and won’t add it back until they follow the standard OAuth flow. I encourage other library authors to do the same.

Why is this so important

OAuth was designed as lower level modern authentication standard that other higher level applications can be built upon. An extension on top of it is the OAuth discovery proposal which in theory would allow you to connect to any provider by just giving it a single top level URL.

So lets say I wanted to connect to Yahoo. I could just do something like:

@yahoo = OAuth::Consumer.new :site=>"http://yahoo.com"

Everything afterwards would be automatic. No specifying of request token urls, authorization urls etc.

What makes this even more interesting is when you start adding higher level API’s on top of OAuth, such as Portable Contacts. This would allow you with a single library with no extra code access your users address book, whether it is on Yahoo, Google, Plaxo or even your own personal address book server. Having a straightforward discoverable protocol without extra overhead makes it simple for developers to access. It removes all the proprietary code exceptions we have to write today.

Having proprietary extensions on something as fundamental as the OAuth token request cycle breaks the beauty and simplicity of PortableContacts and other future standards.

Should standards be dictated by large corporations?

My point about all of this is that I don’t think it is right that large companies try and push through changes to community created standards solely because it will make their life a little bit easier. OAuth came out of small startups and individuals who saw a common problem and wanted to create a solution. We should not just blindly accept every suggestion that comes out of large companies just so we can announce with much excitement that we have the support of Google, Yahoo or Microsoft. I think it’s great that they join in the process, but we should not bend our principles, just for the sake of them joining.

The debate on the mailing list

I have been debating this on the OAuth mailing list and while my initial tone was definitely negative, it was never targeted at any individuals. Unfortunately the discussion has now become more of a personal fight, which I don’t think is particularly useful.

While this particular discussion is about Yahoo I would be equally disturbed by it if any other major provider tried to do the same thing. Yahoo is famous in OAuth circles for their corporate culture and infrastructure leaking into the standards as wast last seen during the OAuth IPR debate last year.

Yahoo has done great work in a whole lot of instances. FireEagle in particular is still one of the best OAuth implementations out there. I just wish they had done a better job of thinking through their corporate OAuth strategy.