Hi All, Just so everyone remembers: "GET" encoded "http://" URLs usually appear en-mass in public lists (from proxy cache logs). If you don't want to "POST" data anyplace, remember to expect "replay attacks" often.
Kind Regards, Chris Drake Friday, October 13, 2006, 7:48:31 PM, you wrote: JH> On 10/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote: >> > True, even one single pass through parameter should do. >> >> This causes the minor inconvenience that the RP will probably now have >> to implement its own parsing, rather than using the framework's >> pre-supplied functions for dealing with urlencoded query strings. >> >> Not a major deal, but I'd guess that this is where the idea to use >> return_to args came from in the first place. JH> return_to arguments can only be trusted if they are taken from the JH> signed return_to parameter, which means parsing the signed return_to JH> parameter anyway. So it's at least no worse. JH> It's better in that the parameters do not now appear twice in the JH> response (once double-encoded) JH> Example of a response with parameter in the return_to: JH> http://a.url/?drink=0xC0FFEE%21&openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521&... JH> Example of a response with hypothetical openid.appdata field: JH> http://a.url/?openid.appdata=drink%3D0xC0FFEE%21&openid.return_to=http%3A//a.url/&... JH> Josh JH> _______________________________________________ JH> specs mailing list JH> email@example.com JH> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs