In OpenID 2.0 section 11.1, we see the following requirement regarding verifying the openid.return_to parameter:<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: verdana; ">Any query parameters that are present in the "openid.return_to" URL MUST also be present with the same values in the URL of the HTTP request the RP received.</span><br>
</blockquote><div><br></div><div>But consider this incoming RP message: (I didn't bother properly URL encoding it since that would just make it harder to read)</div><div><a href="http://rp/authenticate?a=b&a=c&openid.return_to=http%3a%2f%2frp%2fauthenticate%3fa%3db&openid.*">http://rp/authenticate?a=b&a=c&openid.return_to=http%3a%2f%2frp%2fauthenticate%3fa%3db&openid.*</a> (other openid parameters)</div>
<div><br></div><div>In the above GET request, the openid.return_to value has a decoded value of <a href="http://rp/authenticate?a=b">http://rp/authenticate?a=b</a>. You can see that the incoming request matches the requirements as they all keys exist with the same values. However, some keys (specifically 'a' in this example) show up multiple times, and have different values. Depending on the library, this could have adverse security or undesirable altering affects.</div>
<div><br></div><div>I wonder if we should enhance the 2.1 spec to say that the same keys must not appear more than they do in the return_to URL.</div><div>--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
</div>