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

[Recordon, David]

I think it is called DTP. :P

We still need to add rules around what to do if both a GET and POST
parameter with the same name exist.

--David 

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Monday, November 20, 2006 1:34 PM
To: Recordon, David
Cc: specs at openid.net
Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or,OpenID
withREST/SOAP)

Good, we will remove depreciating GET then.

How about you spec an extension for doing your proposal? :-)

-- Dick

On 20-Nov-06, at 1:32 PM, Recordon, David wrote:

> I'd be fine with supporting both, though my preference is what I 
> described in my previous message.
>
> --David
>
> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com]
> Sent: Monday, November 20, 2006 1:05 PM
> To: Recordon, David
> Cc: specs at openid.net
> Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or,OpenID
> withREST/SOAP)
>
>
> On 20-Nov-06, at 12:18 PM, Recordon, David wrote:
>
>> Guessing I was a bit unclear here...
>>
>> What I meant to say was that the spec as it stands today only allows 
>> the use of POST and deprecates the use of GET and 302 redirects.  It 
>> seems that what you're saying is by using GET we're going against a 
>> recommendation by the W3C.  The point I was trying to make was that 
>> even if using GET is against their recommendation, it is deployed 
>> today and working quite well.
>>
>> My preference, from a technical perspective, is changing 2.0 back to 
>> using GET like 1.1 and then defining the mechanism that an IdP can 
>> signal to the RP that there is more data for it to fetch.
>
> Yuck. We are *so* close to having this wrapped and you want to add 
> something new?!?
>
> Using POST works fine as well. We used it in SXIP. Some of the SAML 
> profiles use it. Google uses it in their new SSO API.
>
> We are supporting both now. How about we state that either to be used,

> and clearly they SHOULD use POST if there is more then 2K of data.
> These
> seems to be the most straightforward solution.
>
>
>
>
>
>