+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<[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 > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
