<br><br><div class="gmail_quote">On Thu, Mar 26, 2009 at 9:46 PM, Luke Shepard <span dir="ltr"><<a href="mailto:lshepard@facebook.com">lshepard@facebook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<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:<div class="im"><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></div>
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:<div class="im"><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></div>
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:<div class="im"><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></div>
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>
</span></font></div></blockquote><div><br>For what it's worth, we went through a similar discussion when we were trying to define a version of OAuth for "unregistered" consumers, and are proposing the following there (<a href="http://step2.googlecode.com/svn/spec/unregistered_oauth/latest/oauth-unregistered.html">http://step2.googlecode.com/svn/spec/unregistered_oauth/latest/oauth-unregistered.html</a>):<br>
<br>- use POST by default, to reduce the risk posed by open redirectors (which tend to not redirect on a POST)<br>- when using GET (which can be requested by the consumer), put the sensitive payload into the fragment. This has the performance benefit Luke mentions if the consumer is Javascript, _plus_ also helps with open redirectors - the sensitive payload doesn't hit the servers and most browsers drop it across 302s.<br>
<br>Dirk. <br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
>From Martin:<div class="im"><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></div>
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.<div>
<div></div><div class="h5"><br>
<br>
<br>
On 3/25/09 9:26 PM, "James Henstridge" <<a href="http://james@jamesh.id.au" target="_blank">james@jamesh.id.au</a>> wrote:<br>
<br>
</div></div></span></font><div><div></div><div class="h5"><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="http://mart@degeneration.co.uk" target="_blank">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="http://lshepard@facebook.com" target="_blank">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="http://specs@openid.net" target="_blank">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
<br>
</span></font></blockquote>
</div></div></div>
<br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
<br></blockquote></div><br>