Request for comments: Sorting fields in signature generation

[Dick Hardt]

On 28-Sep-06, at 3:18 AM, Martin Atkins wrote:

> Josh Hoyt wrote:
>>
>>> If that weren't so, then why is there the "openid." prefix to the
>>> parameters in some of the messages?
>>
>> The reason that the parameters have "openid." at the beginning is so
>> that it is clear that they are part of the OpenID protocol message  
>> and
>> not intended to be operated on by the application that is processing
>> the OpenID request. Basically, to reduce the likelihood of name
>> collisions with parameters that the application uses.
>>
>
> An example, just to make doubly sure that everyone knows what's being
> discussed here...
>
> If I have:
> <link rel="openid.server" href="http://www.idp.com/server? 
> user=mart" />
>
> ...then when the OpenID request is made, it's important that the
> argument given there is preserved:
>
> http://www.idp.com/server?user=mart&openid.mode=...&openid.cla...
>
> However, the relying party doesn't want that IDP-specific "user"
> argument passed back to it. In fact, it possibly has its own set of  
> args:
>
> openid.return_url=http://www.relying.com/openid?mode=return
>
> ...so to avoid conflicts between these unqualified namespaces, I  
> believe
> the IDP should only return back the spec-defined openid.whatever  
> args to
> the relying party.
>
> If the relying party needs to round-trip arguments back to itself, it
> can do that by including them in the openid.return_url value as shown
> above, return_url is included in the response signature.

But in OpenID 2.0, we are using POST, not GET, so there is no  
conflict with URL parameters

-- Dick