return_to url in the OpenID responses

[Praveen Alavilli]

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:


   1. 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
   2. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090902/c41ac54d/attachment.htm>