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

[Johannes Ernst]

I'm not sure you guys mean this.

Let's say the service endpoint is
     http://example.com/openid-endpoint?service-class=premium

This means that 'service-class=premium' should suddenly be sent  
around as a POST parameter?

(I realize that this is not a particular good choice for an endpoint  
URL, but I can imagine some places where it may end up that way)

What about this instead:
    When a message is sent as POST, and if an OpenID parameter is  
sent both in the argument list to the URL and in the POST payload,   
the application processing the HTTP request MUST ignore the value of  
the parameter given in the argument list to the URL.

Or, in any case, this rule only applies to OpenID parameters -- we  
should not decree what happens to parameters not in the scope of OpenID.


On Nov 20, 2006, at 13:46, Recordon, David wrote:

> Ah ok, forgot about that paragraph.
>
> --David
>
> -----Original Message-----
> From: Johnny Bufu [mailto:johnny at sxip.com]
> Sent: Monday, November 20, 2006 1:47 PM
> To: Recordon, David
> Cc: Dick Hardt; specs at openid.net
> Subject: Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID
> withREST/SOAP)
>
> David,
>
> On 20-Nov-06, at 1:35 PM, Recordon, David wrote:
>> We still need to add rules around what to do if both a GET and POST
>> parameter with the same name exist.
>
>
> This seems to be already covered, under the "HTTP Encoding" section:
>
> 	When a message is sent as a POST, the application processing
> 	the HTTP request MUST only use the values in the POST body
> 	and MUST ignore any GET parameters.
>
> Not sure if it needs to be emphasized.
>
>
> Johnny
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs