On 29/10/2007, John Ehn <[EMAIL PROTECTED]> wrote: > 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). 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.
>From my reading of the spec, the OP only tries to verify the return_to value if RP discovery succeeds. If RP discovery fails, then return_to verification is not attempted. In the case of an intranet RP (or any other RP that hasn't implemented discovery), any return_to URL that matches the realm should be acceptable. The case where the OP SHOULD NOT return a positive assertion is if: 1. the OP attempts RP discovery 2. RP discovery succeeds 3. the return_to URL is not in the list of discovered RP endpoints James. _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs