I happened to be reviewing the 10th draft of the OpenID 2.0 Authentication spec, when I noticed this nugget in section 5.2.1 of the draft:

[HTTP redirect] method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility.

In place of the HTTP redirect used by OpenID 1.1, is this, in section 5.2.2:

A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated using JavaScript.

The <form> element’s “action” attribute value MUST be the URL of the receiving Web site. Each Key-Value pair MUST be included in the form as an <input> element. The key MUST be encoded as the “name” attribute and the value as the “value” attribute, such that the User Agent will generate a message as specified in Section 4.1.2 (HTTP Encoding) when the form is submitted. The form MUST include a submit button.

This disturbed me somewhat, as it couples OpenID 2.0 auth fairly tightly with HTML and interactive user agents. You may recall my earlier rant decrying OpenID 1.1’s tight browser coupling, which I only recanted when Johannes Earnst showed me how wrong I was. Now, it seems, what I thought to be true about OpenID 1.1 is in fact true of OpenID 2.0.

I emailed Johannes about this, and he suggested I post to specs@openid.net. I did, and startied a thread that ended up going off in another direction, but confirmed my interpretation of the OID 2.0 language.

The gist of the explanation for the change was that OpenID 2.0 is much richer than 1.1, and thus will involve larger message exchanges, and thus the 2K limit imposed by using HTTP redirects and therefore GETs will become a problem, ergo HTTP POST populated by submission of an HTML form is the only option left that is compatible with major browsers without extensions or plug-ins.

The reasoning is sound, and under the circumstances I might’ve made the same call. Clearly, there’s alot of value in using OpenID with REST/SOAP/other technologies, but the OpenID community is moving in a direction that requires REST/SOAP/other bindings be described in separate standards.

So, with the encouragement of Dick and others on the specs list, I’ve put together some thoughts on what OpenID bindings for REST/SOAP/HTTP might look like. I’ve created a page on the OpenID wiki to capture these thoughts.