+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<[email protected]> 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 > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
