+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<[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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
