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
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to