OpenID 2.0 Section 9.2.1

[John Ehn]

Okay.  Can we re-word it then so it's more explicitly stated?  I.E.:

Attempt discovery.
If discovery succeeds, ensure return_to URL is specified in the XRDS
document.  If not present, always return negative assertion.
If discovery fails, assume return_to URL is valid and return assertion.

Thanks!

John Ehn
extremeswank.com

On 10/29/07, James Henstridge <james at jamesh.id.au> wrote:
>
> On 29/10/2007, John Ehn <john at extremeswank.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20071029/26ce4dc8/attachment-0001.htm>