<HTML>
<HEAD>
<TITLE>Re: Defining how OpenID should behave with fragments in the return_to url</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>This thread has been really useful – thanks for the responses everyone. I have a few inline responses to a few different emails, bear with me while I try to unify the thread. <BR>
<BR>
>From Breno:<BR>
> The very legitimate question here is whether it is acceptable for the OpenID spec to define that the query <BR>
> can be encoded in the fragment if a fragment is present in the return_to URL. If the spec were to say it is <BR>
> valid, then there is no incorrect behavior (as no other spec is otherwise violated).<BR>
<BR>
Yup, great point. We can just say that it is valid (as Google and Yahoo have implemented it today) thus blessing this as a potential optimization going forward.<BR>
<BR>
>From Allen:<BR>
> Given that this fragment technique is intended to improve the user experience, <BR>
> especially in the context of a popup window, I think that we may be able to <BR>
> document the correct behavior this in the forthcoming UI Extension.<BR>
<BR>
After thinking a bit more on this, I realized that while performance of the checkid_setup call in the popup is important, it’s a one-time cost so not that big of a deal.<BR>
<BR>
A much bigger issue is the performance of checkid_immediate in an iframe. For Connect, we do the equivalent of that on every single page. For OpenID, I can see a case where a relying party would run a checkid_immediate on every page (to make sure the user was still logged in). In fact, a relying party might want to check multiple OpenID providers on a page load – maybe even dozens or hundreds, potentially. If they did that, then the performance of each call would definitely be a much bigger issue, and this HTTP load would become more important.<BR>
<BR>
>From James:<BR>
> Disallowing post responses limits the use of the more verbose<BR>
> extensions (e.g. attribute exchange). While this might be acceptable<BR>
> for Luke's particular use case, it might leave it unsolved for others.<BR>
<BR>
The POST response is a good point and clearly a valid use case, and I think it’s supported no matter what we decide to do. It’s possible to build a receiver that handles POST params if they are present, but otherwise serves up the correct cache headers and Javascript to handle the GET. That would provide a performance boost in the common case, while still being fully compatible with the spec.<BR>
<BR>
>From Martin:<BR>
> To be honest, I'd be surprised if POST requests from OP to RP worked<BR>
> interoperably today, but the trick of using the # on the end of the<BR>
> return_to URL to signal to a supporting OP "I'm trying to do this<BR>
> completely client-side, so don't do a POST request" works here too.<BR>
<BR>
Maybe having the fragment is a clue, but I’d prefer an even more explicit clue- like what if the RP could say “don’t send POST requests back, just send no more than X chars in the GET no matter what”. Then the OP could just drop data if it went over the limit ... or something.<BR>
<BR>
<BR>
On 3/25/09 9:26 PM, "James Henstridge" <<a href="james@jamesh.id.au">james@jamesh.id.au</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins <<a href="mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:<BR>
> James Henstridge wrote:<BR>
>><BR>
>> On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard <<a href="lshepard@facebook.com">lshepard@facebook.com</a>><BR>
>> wrote:<BR>
>>><BR>
>>> One crude way to do it would be to have the caller specify that they want<BR>
>>> the return_to args simply appended instead of integrated into the URL-<BR>
>>> perhaps an argument like openid.append_return_to_params=true. But that<BR>
>>> sounds hackish and I’d love to hear feedback on a better way to do this.<BR>
>><BR>
>> How would this interact with OpenID providers that respond via a POST<BR>
>> request instead of a GET? This is something they are permitted to do<BR>
>> according to the spec, and may decide to do so even if the<BR>
>> authentication request was started with a GET if the response is large<BR>
>> enough.<BR>
>><BR>
><BR>
> This is a good point, but it seems like again it can be worked around by<BR>
> making openid_reciever.html accept POST requests.<BR>
><BR>
> Unlike the query string, this can't be done completely client side, but it<BR>
> ought to be reasonably simple to set up some kind of rewriterule or other<BR>
> indirection trick to make POST requests to openid_reciever.html actually get<BR>
> served by a non-static endpoint.<BR>
<BR>
Any intermediate caches would also drop their cached versions when<BR>
they see a POST request too (assuming they follow the standards), but<BR>
I suppose it'd still be a win if the POST requests are infrequent.<BR>
<BR>
This is starting to become a lot more complicated than the "simple<BR>
static return_to page" from the initial proposal though.<BR>
<BR>
<BR>
> To be honest, I'd be surprised if POST requests from OP to RP worked<BR>
> interoperably today, but the trick of using the # on the end of the<BR>
> return_to URL to signal to a supporting OP "I'm trying to do this completely<BR>
> client-side, so don't do a POST request" works here too.<BR>
<BR>
Disallowing post responses limits the use of the more verbose<BR>
extensions (e.g. attribute exchange). While this might be acceptable<BR>
for Luke's particular use case, it might leave it unsolved for others.<BR>
It might be worth going back to basics and considering whether there<BR>
are other solutions.<BR>
<BR>
The stated aim was to provide the best user experience possible for<BR>
running an OpenID authentication request through a pop up window and<BR>
then communicating the results back to the main window.<BR>
<BR>
Luke's proposal is one possible solution, but I wouldn't want to<BR>
impose limitations on the specification if there is an alternative<BR>
that also solves the problem.<BR>
<BR>
James.<BR>
_______________________________________________<BR>
specs mailing list<BR>
<a href="specs@openid.net">specs@openid.net</a><BR>
<a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>