Okay. Can we re-word it then so it's more explicitly stated? I.E.:<br><br>Attempt discovery.<br>If discovery succeeds, ensure return_to URL is specified in the XRDS document. If not present, always return negative assertion.
<br>If discovery fails, assume return_to URL is valid and return assertion.<br><br>Thanks!<br><br>John Ehn<br><a href="http://extremeswank.com">extremeswank.com</a><br><br><div><span class="gmail_quote">On 10/29/07, <b class="gmail_sendername">
James Henstridge</b> <<a href="mailto:james@jamesh.id.au">james@jamesh.id.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 29/10/2007, John Ehn <<a href="mailto:john@extremeswank.com">john@extremeswank.com</a>> wrote:<br>> I've been reviewing Draft 12, and noticed this section, which I think will<br>> cause problems for some systems.
<br>><br>><br>> 9.2.1. Using the Realm for Return URL Verification<br>><br>> OpenID providers SHOULD verify that the return_to URL specified in the<br>> request is an OpenID relying party endpoint. To verify a return_to URL,
<br>> obtain the relying party endpoints for the realm by performing discovery on<br>> the relying party (Discovering OpenID Relying Parties). As always when<br>> performing discovery, the discovered URL is the URL of the last HTTP
<br>> response, following redirects. If any redirects are followed when performing<br>> discovery on the realm, verification has failed. If discovery has<br>> successfuly completed, check to make sure that the return_to URL matches one
<br>> of the relying party endpoints.<br>><br>> A realm may contain a wildcard, and so may not be a valid URL. In that case,<br>> perform discovery on the URL obtained by substituting "www" for the wildcard
<br>> in the realm.<br>><br>> To match a return_to URL against a relying party endpoint, use the same<br>> rules as for matching the return_to URL against the realm, treating the<br>> relying party's endpoint URL as the realm. Relying party endpoint URLs MUST
<br>> NOT contain a domain wildcard, and SHOULD be as specific as possible.<br>><br>> If verification is attempted and fails, the provider SHOULD NOT send a<br>> positive assertion to that return_to URL.<br>>
<br>> Providers MAY cache verified return_to URLs.<br>><br>> I think it is a nice idea, however, it does not take into account situations<br>> where a Relying Party may not exist on the public Internet. For instance,
<br>> let's say I have an intranet application. The following is true:<br>><br>> The application is located on a host in my office<br>> My office is connected to the Internet via a NAT firewall (all internal IP
<br>> addresses are not accessible from the Internet)<br>> My application uses OpenID for authentication<br>> A guest worker has been given permission to use my application with their<br>> OpenID provided by another company
<br>> The following should happen:<br>><br>> The user will attempt to log in with their OpenID<br>> My application will send a request to the OpenID Provider<br>> The Provider will attempt to perform RP discovery
<br>> The RP discovery will fail<br>> The OpenID Provider rejects the authentication request<br>> As you can see, for this use case, OpenID would no longer be usable.<br><br>From my reading of the spec, the OP only tries to verify the return_to
<br>value if RP discovery succeeds. If RP discovery fails, then return_to<br>verification is not attempted.<br><br>In the case of an intranet RP (or any other RP that hasn't implemented<br>discovery), any return_to URL that matches the realm should be
<br>acceptable.<br><br>The case where the OP SHOULD NOT return a positive assertion is if:<br> 1. the OP attempts RP discovery<br> 2. RP discovery succeeds<br> 3. the return_to URL is not in the list of discovered RP endpoints
<br><br>James.<br></blockquote></div><br>