OpenID 2.0 Section 9.2.1

[John Ehn]

I've been reviewing Draft 12, and noticed this section, which I think will
cause problems for some systems.


9.2.1.  Using the Realm for Return URL Verification

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 *discovery on
the relying party (Discovering OpenID Relying
Parties)*<http://openid.net/specs/openid-authentication-2_0-12.html#rp_discovery>.
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.

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.

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.

*If verification is attempted and fails, the provider SHOULD NOT send a
positive assertion to that return_to URL. *

Providers MAY cache verified return_to URLs.

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:

   - The application is located on a host in my office
   - My office is connected to the Internet via a NAT firewall (all
   internal IP addresses are not accessible from the Internet)
   - My application uses OpenID for authentication
   - A guest worker has been given permission to use my application with
   their OpenID provided by another company

The following should happen:

   - The user will attempt to log in with their OpenID
   - My application will send a request to the OpenID Provider
   - The Provider will attempt to perform RP discovery
   - The RP discovery will fail
   - The OpenID Provider rejects the authentication request

As you can see, for this use case, OpenID would no longer be usable.

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.

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.

If I'm wrong, please let me know.

Thank you,

John Ehn
extremeswank.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20071029/2d481650/attachment-0001.htm>