return_to url in the OpenID responses

[George Fletcher]

+1 for relay state and signing all parameters

Great point about discovery and dynamic parameters!

Thanks,
George

Breno de Medeiros wrote:
> +1 for a relay state
>
> In my view the OpenID spec is broken with regards to the return_to
> URL. For instance, how do you reconcile the need for dynamic elements
> in the return_to URL with the recommended behavior of putting the
> return_to URL in the discovery document?
>
>
> On Wed, Sep 2, 2009 at 11:58 AM, Praveen
> Alavilli<praveen.alavilli at gmail.com> wrote:
>   
>> Hi,
>> I wasn't sure if this was ever discussed so sending it to the specs list.
>> Currently the "openid.return_to" url param is a required parameter in all
>> OpenID positive assertions. I understand the reasons behind it, but I wonder
>> if passing back the whole return_to url (along with it's query params) as
>> response param is really required. Returning the return_to url in the
>> response just duplicates the same data that's already included in the
>> response url contributing to the problem of the response url length close to
>> or in some cases exceeding the max length allowed by certain browsers
>> (IE!).
>> Given that all the query parameters attached to the return_to param are
>> anyway included in the redirect url, and the spec explicitly says that it's
>> up to the RP to ensure those params are not modified by outside parties, can
>> we:
>>
>> modify the signing method to include all query parameters (not just openid
>> params) in the signature base string (follow something like the OAuth
>> signing mechanism) and modify the openid.return_to param in the response to
>> be just the request uri part (not including the rest of the non-OpenID RP
>> specific parameters), OR
>> add a new request parameter (say openid.rpState) that RPs can use to store
>> their state/context info so they don't need to include them in the return_to
>> url and so the OPs sign it along with the rest of the openid parameters in
>> the response ?
>>
>> I know that there have been discussions going on about adding support for
>> artifact binding to OpenID in 2.1 but that just unnecessarily adds
>> additional requests for every OpenID login request. Not sure if the
>> latencies incurred due to those are worth the effort. The other option to
>> use a POST instead of a GET to avoid the url length issues causes bad back
>> button user experience.
>> Any other thoughts ?
>> thanks
>> Praveen
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>     
>
>
>
>