OpenID 2.0 Section 9.2.1

2007-10-29 Thread 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
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID 2.0 Section 9.2.1

2007-10-29 Thread James Henstridge
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


Re: OpenID 2.0 Section 9.2.1

2007-10-29 Thread 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 [EMAIL PROTECTED] wrote:

 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