<div>I've been reviewing Draft 12, and noticed this section, which I think will cause problems for some systems.</div>
<div> </div>
<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
<h3>9.2.1. Using the Realm for Return URL Verification</h3>
<p>OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing <a class="info" href="http://openid.net/specs/openid-authentication-2_0-12.html#rp_discovery">
<strong><font color="#990000">discovery on the relying party<span> (</span><span class="info">Discovering OpenID Relying Parties</span><span>)</span></font></strong></a>. As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints.
</p>
<p>A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting "www" for the wildcard in the realm. </p>
<p>To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible.
</p>
<p><strong>If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL. </strong></p>
<p>Providers MAY cache verified return_to URLs. </p></blockquote>
<p>I think it is a nice idea, however, it does not take into account situations where a Relying Party may not exist on the public Internet. For instance, let's say I have an intranet application. The following is true:
</p>
<ul>
<li>The application is located on a host in my office</li>
<li>My office is connected to the Internet via a NAT firewall (all internal IP addresses are not accessible from the Internet)</li>
<li>My application uses OpenID for authentication </li>
<li>A guest worker has been given permission to use my application with their OpenID provided by another company</li></ul>
<div>The following should happen:</div>
<ul>
<li>The user will attempt to log in with their OpenID</li>
<li>My application will send a request to the OpenID Provider</li>
<li>The Provider will attempt to perform RP discovery</li>
<li>The RP discovery will fail</li>
<li>The OpenID Provider rejects the authentication request</li></ul>
<div>As you can see, for this use case, OpenID would no longer be usable.</div>
<div> </div>
<div>The first reaction will be "well, this is a SHOULD, not a MUST". That's all well and good, however, this will cause any Intranet-based authentiation request to fail for any provider that decides to implement this SHOULD, which means we'll have minor frustration at least (you can switch to a provider that doesn't implement this SHOULD), or abandonment of OpenID entirely at worst.
</div>
<p>I believe we should allow the user to be warned about the discrepency, but all them to continue the authentication request if they are aware that RP is not accessible from the Internet.</p>
<p>If I'm wrong, please let me know.</p>
<p>Thank you,</p>
<p>John Ehn<br><a href="http://extremeswank.com">extremeswank.com</a></p>