return_to url in the OpenID responses

[Praveen Alavilli-2]

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

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Breno de Medeiros]

+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@...> 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@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[George Fletcher-2]

+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@...> 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@...
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>    
>
>
>
>  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Nat Sakimura]

+1 for a relay state, but not for the size thing. This is a completely
separate issue than the Artifact binding.

Artifact binding is needed anyways for several reasons.

For example, mobile browsers etc., an Artifact binding is essential.
You must not think that that the transmission only happens over a fast
connection. In mobile scenarios, typically, the browser session is
over the slow connection while the server to server connection is over
a fast connection. So, latency-wise, the Artifact binding is going to
be much better, in fact, orders better, and kinder to an OP from the
point of view of number of simultaneous port that they have to keep
open. Also, you are talking about IE limit, but mobile browser limit
is much more severe, like 256 bytes per a GET query.

In addition, I would like to point out that over 70% of the traffic is
now generated from the mobile browsers. In the U.S., it might not have
happened yet, but you may be heading towards the direction as well.
People do not use a PC when it suffice with a Phone. User experience
is much better that way.

I would further say this: A protocol or service that can only be
provided over a single channel like PC is DEAD. It has to be provided
over mobile, PC internet, TV internet, etc. simultaneously. This is
not my word. This is the testimony from the EC (Electric Commerce)
consortium (I need to check their English name though...) at the
Japanese government meeting that discusses the authentication
guideline. IMHO, EU and US will come to the same state in a few years.

Also, the Artifact is needed for security reasons as well. You need it
for LoA2+. With the advent of Government 2.0, we need it NOW. We
should have done that long before.

=nat

On Thu, Sep 3, 2009 at 3:58 AM, Praveen
Alavilli<praveen.alavilli@...> 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@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs