Re: Defining how OpenID should behave with fragments in the return_to url

2009-03-25 Thread James Henstridge
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:
 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.

How would this interact with OpenID providers that respond via a POST
request instead of a GET?  This is something they are permitted to do
according to the spec, and may decide to do so even if the
authentication request was started with a GET if the response is large
enough.

If it helps, you could reproduce such a response with a form like:

form action=http://open.lukeshepard.com/openid_receiver.html?query#hash;
  method=post accept-charset=UTF-8
  input type=hidden name=openid.ns value=...
  ...
  input type=submit value=Submit
/form

This proposal sounds like something that will work most of the time
but fail in a number of valid cases.

It'd be nice to support the popup based authentication workflow well,
but I am not convinced that relying on this quirk is the right way to
do so.

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


Re: Defining how OpenID should behave with fragments in the return_to url

2009-03-25 Thread Martin Atkins

James Henstridge wrote:

On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:

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.


How would this interact with OpenID providers that respond via a POST
request instead of a GET?  This is something they are permitted to do
according to the spec, and may decide to do so even if the
authentication request was started with a GET if the response is large
enough.



This is a good point, but it seems like again it can be worked around by 
making openid_reciever.html accept POST requests.


Unlike the query string, this can't be done completely client side, but 
it ought to be reasonably simple to set up some kind of rewriterule or 
other indirection trick to make POST requests to openid_reciever.html 
actually get served by a non-static endpoint.


To be honest, I'd be surprised if POST requests from OP to RP worked 
interoperably today, but the trick of using the # on the end of the 
return_to URL to signal to a supporting OP I'm trying to do this 
completely client-side, so don't do a POST request works here too.



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


Re: Defining how OpenID should behave with fragments in the return_to url

2009-03-25 Thread James Henstridge
On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote:
 James Henstridge wrote:

 On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com
 wrote:

 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.

 How would this interact with OpenID providers that respond via a POST
 request instead of a GET?  This is something they are permitted to do
 according to the spec, and may decide to do so even if the
 authentication request was started with a GET if the response is large
 enough.


 This is a good point, but it seems like again it can be worked around by
 making openid_reciever.html accept POST requests.

 Unlike the query string, this can't be done completely client side, but it
 ought to be reasonably simple to set up some kind of rewriterule or other
 indirection trick to make POST requests to openid_reciever.html actually get
 served by a non-static endpoint.

Any intermediate caches would also drop their cached versions when
they see a POST request too (assuming they follow the standards), but
I suppose it'd still be a win if the POST requests are infrequent.

This is starting to become a lot more complicated than the simple
static return_to page from the initial proposal though.


 To be honest, I'd be surprised if POST requests from OP to RP worked
 interoperably today, but the trick of using the # on the end of the
 return_to URL to signal to a supporting OP I'm trying to do this completely
 client-side, so don't do a POST request works here too.

Disallowing post responses limits the use of the more verbose
extensions (e.g. attribute exchange).  While this might be acceptable
for Luke's particular use case, it might leave it unsolved for others.
 It might be worth going back to basics and considering whether there
are other solutions.

The stated aim was to provide the best user experience possible for
running an OpenID authentication request through a pop up window and
then communicating the results back to the main window.

Luke's proposal is one possible solution, but I wouldn't want to
impose limitations on the specification if there is an alternative
that also solves the problem.

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