This looks similar in principle to the "AJAX"-ish (though not really AJAX at all) mode of OpenID that was in the early demos but no-one actually seems to have implemented in practice. The trick there was to do the OP dance in a hidden iframe and have the return_to page communicate with the outer page in much the same way as the popup does.

However, the optimization of doing it with the fragment identifier is interesting.

My first concern was backward compatibility, but it actually looks like we get back-compat by accident as long as openid_reciever.html is able to actually process the query string if it's present.

Here's a strawman:

* If the return_to URL ends with a # character, a supporting OP (or an OP that's doing this by accident) should make the return_to URL by appending the ? after the # and then adding the query string arguments as normal.

* The non-fragment part of the URL MUST support having the arguments passed in the *real* query string. In this case, the fragment part should be ignored and is likely to be the empty string anyway.

This allows OPs that don't work in the way you suggest to still work, albeit with worse UI performance due to the extra round-trip that will inevitably be generated.

As far as I can tell, your openid_reciever.html can still be a static file in the query string case, becausee most existing web servers will accept and silently drop query string arguments on URLs that address static files, and the full URL should be available client side in docment.location to allow you to retrieve the query string.

It'd be good to see how more existing OPs behave when presented with a return_to URL that ends with a #. Having MyOpenID fail is a show-stopper for the above approach IMHO, but hopefully they will "fix" their implementation if they are the only one broken.

(I've quite deliberately said *ends with* rather than *contains* a # here, because that's a simpler thing to catch for folks who will need to fight their local URI-mangling library in order to implement this, which I assume applies to MySpace -- I presume that their correct behavior came "for free" with the .NET System.Net.Uri class.)


Luke Shepard wrote:
Hi-

I've noticed an ambiguity with the way URLs are handled that exists in the 
current spec. I'm hoping we can resolve it for OpenID 2.1.

When we move the OpenID transaction into a popup window, we need a way for the 
popup to communicate back with the parent. The way to do this is to set a 
return_to URL that, when loaded, reads the parameters and communicates with the 
parent window somehow.

Here's a description of a technique:
http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/

A simple way to do this is to have a simple receiver. The response will append 
query parameters:

http://open.lukeshepard.com/openid_receiver.php?openid.ns=......

However, there is a small performance problem with this approach. The user will 
see a blank-looking popup for a moment while the server processes the OpenID 
arguments. An optimization is to put up a simple, cacheable static HTML file 
that chucks the OpenID params back to the parent frame. The parent can then 
provide some visual feedback to the user while it sends the OpenID parameters 
off for processing. This results in a snappier experience.

If the static HTML file has no parameters and sends out long-lived cache 
headers, then the response won't even trigger a server load, and the whole 
process can appear faster to the user. In this case, the response would look 
like this:

http://open.lukeshepard.com/openid_receiver.html#openid.ns=......

Note that the hash appears instead of a question-mark. That tells the browser 
that it doesn't need to load an extra file, and it can save perhaps a quarter 
or half second of latency for the user on average.

Okay, so the point is that different OpenID providers currently interpret the 
hash differently. I think we should explicitly define a behavior that makes 
sense and accomodates the above suggestion. Here's how they currently behave.

When given a return_to of 
http://open.lukeshepard.com/openid_receiver.html?query#hash

Google: 
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=....
Yahoo: 
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=....
MySpaceID: 
http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=....#hash
MyOpenID: fails outright - "invalid return_to"

By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. But the 
"correct" way doesn't allow the performance optimization listed above. I'd like 
to see a way to accommodate the hash url.

One crude way to do it would be to have the caller specify that they want the 
return_to args simply appended instead of integrated into the URL- perhaps an 
argument like openid.append_return_to_params=true. But that sounds hackish and 
I'd love to hear feedback on a better way to do this.

Also, let me know if this is the wrong list or whatever.

thanks,
- Luke



------------------------------------------------------------------------

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

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

Reply via email to