Problem with nonces and HTTP GET

[John Bradley]

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 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.
> 
> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100122/d2719e2d/attachment.htm>