On 5-Feb-07, at 11:39 PM, Dick Hardt wrote: >> The best way to resolve this issue is to define a way for the OP to >> verify that the return_to URL is actually a valid OpenID endpoint, >> and >> to also verify its association. >> >> I propose that an RP's return_to url expose an interface to allow >> it to >> identify itself as an OpenID 2.0 endpoint, and to also identify its >> association with the OP. Obviously, OPs must not follow redirects >> when >> interrogating the RP's endpoint. > > Good suggestion on how to resolve. Keen to see what others think.
Another simpler (though maybe not as solid) solution would be for the OP to perform a fetch on the return_to URL and present the final URL - after following the redirects - in the message to the user. So the user will actually see that he's about to go to http://www.jyte.com, for: return_to=http://www.aol.com/ams/clickThruRedirect.adp?1,2,http:// www.jyte.com If the rogue RP further tries to hide itself by setting realm=*.aol.com, the realm verification performed by the OP will fail (again, using the return_to URL after following redirects). Johnny _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
