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

Mon Nov 20 19:57:10 UTC 2006

If so, you are solving a different problem than I like to solve --  
and only a subset of the problem that OpenID 1.x solves already.

With OpenID 1.x, we can pre-assemble an HTTP GET request that allows  
to access a protected resource, completely out of the blue in a  
single round-trip. Just like HTTP BasicAuth (i.e. I don't need to  
have a session cookie first). We can apply the exact same approach to  
all other HTTP verbs.

We have some code where this is very useful -- to pre-assemble the  
authenticated call for Drummond's authenticated bookmark use case.  
(no redirect from the Relying Party required)

Are you saying you want OpenID Auth 2.0 to not do that any more, and  
generally require a POST first whose result is a session cookie? If  
so, then I would agree that this is a consistent design, but a quite  
different one than OpenID 1.x has so far. But I will argue that I  
like the Open 1.x design much better, not just on efficiency grounds.

I don't understand the line you are drawing about what to move via  
additional HTTP headers and what not. THe only line I see there is  
what standard browsers do today without extensions, and what not. I  
think we'd all be happier if all OpenID parameters moved into the  
HTTP headers, won't we?

On Nov 19, 2006, at 23:01, Dick Hardt wrote:

> Johannes
>
> We are not authenticating a POST, GET or PUT call.
>
> We are using HTTP to move around identity protocol messages. If we  
> were wanting to authenticate the application calls of POST, GET,  
> PUT, then we would be using HTTP headers. That essentially is what  
> happens after OpenID is over. The RP sets a cookie that it then  
> checks on all subsequent POST, GET and PUT calls to determine  
> authorization of the call.
>
> -- Dick
>
>
> On 19-Nov-06, at 8:09 PM, Johannes Ernst wrote:
>
>> The fundamental error, in my view, is to say "we can only
>> authenticate POST'd operations". Of course, sometimes one does want
>> to authenticate POST operations, such as in order to POST >2KB
>> identity information to some relying party. But in many other cases,
>> we want to GET information or DELETE information or PUT information
>> or OPTIONS information etc. In my view, there is no need whatsoever
>> to limit OpenID Auth to the POST operation -- it disallows many valid
>> use cases, and I'm against that.
>>
>>
>> On Nov 19, 2006, at 20:02, Recordon, David wrote:
>>
>>> I've chatted with Brad a decent amount about this over the past few
>>> weeks, but still am unsure of what the "right" thing to do here
>>> is.  The
>>> reason behind deprecating GET and using POST instead was so that
>>> larger
>>> payloads could be moved (it is commonly agreed upon not to move
>>> over 2K
>>> of data via a GET URL) without having to deal with both GET and POST
>>> parameters (ie a POST request to http://server.com/endpoint/?foo=bar
>>> with the POST variable "foo" as well).  I was concerned with browser
>>> support in doing this, but was assured that it wouldn't actually  
>>> be a
>>> problem.  So now it seems we're back to the drawing board around
>>> this...
>>>
>>> I agree with Brad that the right solution is defining how the OP  
>>> tells
>>> the RP that there is more data and provides a key to access it.   
>>> That
>>> fits with the description of OpenID being an interoperable
>>> framework of
>>> small specifications.
>>>
>>> With that said, I do agree that just throwing all the data into POST
>>> allows for simpler implementations at the cost of some browser
>>> trickery
>>> and potentially poor user experiences.
>>>
>>> In the spec itself, we also talk about how OPs should not rely on
>>> scripting for various reasons.
>>> http://openid.net/pipermail/specs/2006-November/000904.html
>>>
>>> Can anyone provide a reason, beyond the 2K limit since there are  
>>> other
>>> ways to address that problem, why POST only is the superior  
>>> solution?
>>>
>>> --David
>>>
>>> -----Original Message-----
>>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
>>> Behalf Of Brad Fitzpatrick
>>> Sent: Saturday, November 18, 2006 4:31 PM
>>> To: John Kemp
>>> Cc: specs at openid.net
>>> Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID
>>> withREST/SOAP)
>>>
>>> On Sat, 18 Nov 2006, John Kemp wrote:
>>>
>>>> Dick Hardt wrote:
>>>>>>
>>>>>> But why deprecate support for redirects? I'd (still) like to see
>>>>>> OpenID implementations that do support browsers without JS turned
>>> on .
>>>>>
>>>>>
>>>>> As stated a number of times, because the payload is not big enough
>>>>> with GET redirects. It is with JS POST redirects.
>>>
>>> The alternative is to say OpenID can't pass big messages in core
>>> protocol messages and there could be an extension for how to do it
>>> out-of-band when needed.
>>>
>>>>> 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?
>>>
>>> Exactly.  In the common case, they'll be small, easily within a GET
>>> request.  But we're throwing out the common case and designing  
>>> for the
>>> hypothetical cases.  *sigh*
>>>
>>>>> We will see if the JS requirement is an issue. I do not think  
>>>>> it is
>>>>> given what I know now.
>>>>
>>>> Well, admittedly, if no-one except me thinks that redirects  
>>>> should be
>>>> supported in OpenID 2.0, then I certainly expect to lose that
>>>> argument
>>>
>>>> ;)
>>>
>>> I hate making GET deprecated.  I don't mind POST also existing
>>> (well, I
>>> do mind, but not enough to fight it), but I definitely think GET  
>>> needs
>>> to stay as a equally recommended method.  I hate the idea of
>>> JavaScript
>>> being necessary for a simple auth request.
>>>
>>> - Brad
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>