Hey Breno, our emails crossed I guess. It sounds like we both had the same idea. :) -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
On Fri, Jan 22, 2010 at 11:18 AM, Andrew Arnott <[email protected]>wrote: > I agree with Allen, although to resurrect an old idea I once suggested, > Yahoo could observe that the return_to URL is HTTP only and do its own > stateful redirect (with an artifact payload to itself) to HTTP *before* doing > the POST to the RP, which would: > > 1. use POST instead of GET > 2. avoid the SSL warning to users > 3. do so without any changes to the spec or RPs > > The cost of course is that the redirect within Yahoo is stateful, which may > not scale as well as their current implementation. > > Of this isn't a Yahoo-specific problem, of course, but since the example > came up... > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Fri, Jan 22, 2010 at 10:59 AM, Brian Kissel <[email protected]>wrote: > >> +1 Allen, here’s what I get on HuffPo, not very compelling and probably >> a trigger to “Cancel” to most users. We need to fix this ASAP! >> >> >> >> >> >> Cheers, >> >> >> Brian >> >> *___________* >> >> * * >> >> *Brian Kissel <http://www.linkedin.com/pub/0/10/254>* >> >> CEO - JanRain, Inc. >> >> [email protected] >> >> Mobile: 503.342.2668 | Fax: 503.296.5502 >> >> 519 SW 3rd Ave. Suite 600 Portland, OR 97204 >> >> >> >> *Increase registrations, engage users, and grow your brand with RPX. >> Learn more at **www.rpxnow.com* >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Allen Tom >> *Sent:* Friday, January 22, 2010 10:43 AM >> *To:* Andrew Arnott; John Bradley; Breno de Medeiros; specs >> *Subject:* Re: Problem with nonces and HTTP GET >> >> >> >> The SSL security warning is a really terrible UX, and I agree that it >> doesn’t make sense to warn on POST but not on GET. >> >> Yahoo is running into the 2KB limit (and the associated SSL warning) with >> alarming frequency and it’s really hurting OpenID relative to the >> proprietary SSO solutions. >> >> For a real live example of how the giant AX names are hurting OpenID, see >> http://www.huffingtonpost.com – click on the Login link, then the >> “Connect with Yahoo” button. This kicks off the Hybrid OpenID+Oauth+AX flow >> which requires a POST response – forcing the user to click through a >> security warning to complete the sign in flow. The non-OpenID SSO choices >> (Facebook/Twitter/GFC) do not have this issue. >> >> With regards to changing browsers to not display SSL warnings for POST, or >> relying on smart OpenID clients – we really need a solution right now, since >> the proprietary alternatives are rapidly being adopted. >> >> WRT the nonce – I think it would make more sense for RPs to just check the >> timestamp, and allow replay for a “narrow” window, like 10 minutes. There >> are many legitimate reasons why a request could be replayed – intermediate >> proxy servers might do weird things, the user might hit reload/back/forward >> etc. >> >> Allen >> >> >> On 1/22/10 10:06 AM, "Andrew Arnott" <[email protected]> wrote: >> >> Ideally we could use POST, but avoid the browser warning that information >> is crossing the SSL world into the non-SSL world. This might be arguable >> anyway since sending information can be done with GET or POST, so why warn >> for POST and not for GET? If we can get browsers to not warn for POST we're >> gold. >> >> Alternatively, and perhaps more likely, if we're moving in the direction >> of smart client browser (plugins), and these have been shown to benefit from >> extensions to the OpenID spec, perhaps we can leverage these to always use >> POST without displaying the warning to the user somehow. >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> >> >> On Fri, Jan 22, 2010 at 9:14 AM, John Bradley <[email protected]> >> wrote: >> >> The big problem with POST is RP's that use non-ssl endpoints. >> >> One possibility is that the IdP could look at the return_to and discover >> if it is safe to use POST. >> >> In SAML SSO POST is the most common way to return the token. >> >> The other option is artifact binding. That way the nonce is not in the >> GET, though you probably wind up with the same effect if the RP tries to >> resolve the artifact more than once. >> >> John B. >> On 2010-01-22, at 12:39 PM, Andrew Arnott wrote: >> >> HTTP GET is supposed to be completely effect-free on the server. But >> nonces in OpenID messages violate that aspect of the HTTP spec, since any >> subsequent GET with the same positive assertion will (or should) fail. I >> speculate that some random login failures on StackOverflow < >> http://meta.stackoverflow.com/questions/32247/cant-login-to-so-with-openid-the-signature-verification-failed/36583#36583> >> may be caused because a browser, an accelerator plugin, or a proxy >> attempted to repeat the assertion-carrying GET request (since that's >> supposed to be safe), and a subsequent request is the one whose response is >> displayed in the browser, failing user login. >> < >> http://meta.stackoverflow.com/questions/32247/cant-login-to-so-with-openid-the-signature-verification-failed/36583#36583> >> >> POST is a better fit with the HTTP spec for how the message is actually >> processed on the server. I know lately we've been looking for ways to cram >> more data into < 2KB payloads so we can get off POST and onto GET since the >> user experience is better. But I wonder if we can put our heads together >> and figure out how to have our cake and eat it too with this nonce problem. >> This error doesn't come up often, but it can come up, apparently does come >> up, and is a natural side-effect of the way OpenID communicates. >> >> Any ideas? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >
<<image001.png>>
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
