The Equal Access Principle

(Or, Yes! Your Crappy Hosting Service and Silly Language Should Work)

EqualityInnovation on the web comes from many different directions, and a surprising amount from people with very limited resources. The falling costs of hosted environments and the availability of cloud services like Amazon’s EC2 and S3, are bringing a whole new dimension to what a web application is, and the profile of the people who build them.

If you go back and read my first few posts to the OAuth mailing list, you will see how my initial attitude was to treat everything as a C++ developer. What am I talking about? The attitude that developers always have full access to every feature of the hardware, operating system, and network, and should take full advantage of it. The attitude that treats everything as if it was as easily accessible as making an HTTP GET request. While this is almost always true in C++, it is far from true in many other languages.

I am getting a lot of this attitude now from folks at the W3C and IETF when talking about new specifications. It usually comes up when talking about HTTP methods such as OPTIONS or using DNS for discovery. One of the key requirements in my Discovery and HTTP analysis is Scale Agnostic:

Support large and small providers. Any solution must work for a small hosted website as well as the world largest portal. It must be flexible enough to allow developers with restricted access to the full HTTP protocol (such as limited access to request headers) to be able to both provide and consume metadata information. It should also cache well and allow reuse of code and data.

I call this the Equal Access Principle . The principal, simply put, asks protocol designers not to be snobs. It states that protocols should be able to operate not only on the most powerful frameworks, but within the constraints of the limited frameworks which are part of the web reality. It is a sort of socialism for protocol architecture. We take away some power from the top to make sure those closer to the bottom can also play along.

When working on protocols at the network level such TCP and even HTTP, it is perfectly acceptable to work with the assumption that application developers will have full access to most system resources. But protocols intended for web developers must take into account the heavy limitations imposed by modern scripting languages and production environments. If you want a client-side script to be able to play along, such as JavaScript, a DNS call might be a real problem.

How far to go is up to each specification. It is hard to tell how much should a protocol try to push the limits and inspire limited platforms to improve. When working on OAuth, we constantly tried to balance the security and usability needs with the limited capabilities of PHP, JavaScript, Flash, etc. Many of the steps in signing OAuth requests are there because not every platform gives developers access to the raw HTTP request header.

On the other hand, while designing host-meta, we decided to limit the protocol to those with access to the HTTP server root. It made sense for host-meta because the cost of buying a custom domain and hosting HTTP resources is so low, it is practical for anyone to implement.

One of the first successful specifications to promote the Equal Access Principle is OpenID. While other protocols take into account such limitations (JSON is one example), the authors of the first OpenID specification (and later the authors of the Yadis protocol) made it their top priority. If you study the protocol, the Equal Access Principle marks are all over the place.

The irony with OpenID, is that it takes such extreme measures attending to the weak, it significantly disadvantages the strong. The requirement to add headers or elements to every OpenID-capable URI, or risk problems with caches using content negotiation has led many of the large providers to invent hacks to make OpenID work.

The Equal Access Principle dictates equality. It doesn’t matter how big or small you are, the protocol should find ways to work well for both.