Backwards compatibility

Johannes Ernst at
Mon Sep 25 18:37:16 UTC 2006

On Sep 25, 2006, at 11:05, Dick Hardt wrote:

> On 25-Sep-06, at 10:59 AM, Johannes Ernst wrote:
>>>>  I don't understand why we should make it hard (impossible?) to  
>>>> use OpenID authentication with verbs other than POST.
>>> How would you propose OpenID use the other verbs?
>> If there a mechanism to authenticate an HTTP GET request (as  
>> OpenID 1.1 provides, of course), use the exact same mechanism to  
>> authenticate any other verb. The authentication mechanism does not  
>> depend on which verb it is at all, and in my view, we should not  
>> introduce a dependency (auth on GET, or POST, or any other verb)  
>> where none is needed.
> OpenID authentication is currently the application layer, not the  
> protocol layer.

Not really. The WS-* stack being the counter-example.

> I agree that at some point when supporting HTTP Auth, then it would  
> make sense to support all verbs.
> Right now, we are talking about how the request and response get  
> sent around, which makes sense to use POST.

I didn't say it doesn't make sense to use POST. I did say it does not  
make sense to limit it to POST.

Consider somebody writing a WebDav client that wishes to use OpenID  
to authenticate against the WebDav server. Instead of executing the  
HTTP/WebDav verb that they want to execute, they first have to do an  
HTTP POST that has nothing to do with their WebDav use case, then  
capture a cookie and reuse the cookie for the real WebDav request  
they want to make? And there is no need for such a kludge -- just let  
them sign the URL as in regular OpenID 1.1, but use the PUT verb or  
whatever other verbs they'd like to use.

I hope we at NetMesh are not the only ones who have met people who  
want to do exactly that, and some variations on it?

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
URL: <>
-------------- next part --------------

More information about the specs mailing list