OpenID 2.0 Section 9.2.1
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
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
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
