OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

[Johannes Ernst]

On Nov 19, 2006, at 14:02, Dick Hardt wrote:

> On 18-Nov-06, at 9:46 PM, Johannes Ernst wrote:
>
>> On Nov 18, 2006, at 15:34, John Kemp wrote:
>>
>>>> OpenID 1.1 did not have a large payload. We expect the payloads  
>>>> to be
>>>> much larger with OpenID 2.0.
>>>
>>> I guess the payload size will vary according to the RP and IdP
>>> implementations, no?
>>
>> Yes. And so far the only need for large payload sizes that I have  
>> seen relate to a still somewhat controversial spec that will only  
>> be implemented by less than 100% of all RPs and IdPs (how far less  
>> we can all guess).
>>
>> Making something that has much broader appeal (auth) substantially  
>> more restrictive because of the needs of another spec, that uses  
>> it, and that may not even be implemented by everybody, sounds like  
>> an architectural no-no to me. The obvious workaround: if that  
>> additional spec only works with one of the several alternatives  
>> supported by the auth spec, make the additional spec require to  
>> use that particular mode (POST) only when it is used.
>
> Controversy?  now you are just throwing mud!

Not my intention. Just stating the facts, as I see them. Feel free to  
disagree with my take on the facts. [but that's not actually what  
this thread is all about, so if you'd like to discuss this item,  
let's make this a separate thread.]

Also, feel free to disagree with my "architectural no-no". After all,  
maybe I'm wrong and you can show me how I'm wrong!

> The protocol is for more then authentication, and it is changing  
> state. Per W3C, a GET should not be changing state.

I am familiar with the HTTP verbs, and the fact that returning  
different results to different clients (e.g. those with a session  
cookie or not, or those who produce a valid credential) is a bit  
outside of the scope of (original) REST.

The question here, though, is inhowfar we do something genuinely new  
here, or it maps onto existing practice. I would argue that there  
should be a perfect architectural parallel between:
  - a plain HTTP GET request
  - the same HTTP GET request, with a Http AuthBasic credential
  - a plain HTTP PUT request (to pick an HTTP verb at random)
  - the same HTTP PUT request, with an Http AuthBasic credential
and, on the other hand
  - a plain HTTP GET request
  - the same HTTP GET request, with OpenID Auth parameters that  
authenticate the user for this request
  - a plain HTTP PUT request (to pick an HTTP verb at random)
  - the same HTTP PUT request, with OpenID Auth parameters that  
authenticate the user for this request

I don't see any parallel between
  - a plain HTTP GET request
  - the same HTTP GET request, with a Http AuthBasic credential
  - a plain HTTP PUT request (to pick an HTTP verb at random)
  - the same HTTP PUT request, with an Http AuthBasic credential
and, on the other hand
  - a plain HTTP GET request
  - the same HTTP GET request, put now using POST in the protocol,  
with OpenID Auth parameters that authenticate the user for this request
  - a plain HTTP PUT request (to pick an HTTP verb at random)
  - first, an HTTP POST request to authenticate, then to obtain a  
session cookie (which is outside of the scope of OpenID Auth in any  
case), and then, in a second step, to perform the same HTTP PUT  
request, showing the session cookie.

If the first of these two alternatives can be done -- which they can  
-- why would we pick the second one?

By the way, I would disagree with the notion that authentication in  
itself changes state at all.





Johannes Ernst
NetMesh Inc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openid-relying-party-authenticated.gif
Type: image/gif
Size: 903 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061119/f84d25db/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061119/f84d25db/attachment-0005.gif>
-------------- next part --------------
  http://netmesh.info/jernst