[OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)

[Johnny Bufu]

On 11-Mar-08, at 10:30 AM, Noah Slater wrote:

> On Mon, Mar 10, 2008 at 10:25:35AM -0700, Johnny Bufu wrote:
>> By your reasoning, if URL-1 303-redirects to URL-2, which in turn  
>> sends
>> a "welcome to URL-2" in the HTML body, a browser fetching URL-1  
>> SHOULD
>> (or MUST?):
>>
>> - display URL-1 in the location bar
>
> No, it is fine to follow the redirect.

Following the redirect and using (displaying) the new URL in the  
location bar are two different things.

>> - parse the HTML content and replace every appearance of URL-2 with
>> URL-1
>
> No, it is fine to show the new page.

Why are both of these fine for the browser, and not fine for the  
OpenID discovery agent?

>> I believe this scenario is closer to the absurd than the current  
>> state of
>> all major browsers to display URL-2, regardless which of the
>> 301/302/303/307 redirect types were followed.
>
> Clearly, this would make no sense.

It should then equally make no sense for the OpenID discovery.

>> If all browsers do this, I don't see why OpenID discovery can't.
>
> Sure, OpenID should be free to follow the redirects and parse the  
> HTML found at
> the new location for any delegation link elements etc, in fact, I  
> would very
> much hope that OpenID continues to do this.
>
> I think you have misunderstood my problem though. When the OpenID  
> agent follows
> this redirect to the new location and finds the delegation server,  
> processes the
> login and what have you, I am saying that when it remembers your  
> OpenID for
> future uses or for display on a website it should use the original  
> URI and not
> the one that was found by redirection.

Here you're stepping into the semantics that OpenID defines (User- 
supplied ID vs Claimed ID), and stating an opinion about how you  
think they should work. The Claimed ID is not in the scope of the  
HTTP RFC at this point.


> As the HTTP RFC clearly states, the second URI is not a replacement  
> for the
> first even though the content available from dereferencing it can  
> be used.

Since OpenID defines the two distinct entities on top of the HTTP  
protocol, I still don't see how your inference can apply to anything  
else than the User-supplied ID -- this is the only one I can see in  
the scope of the HTTP RFC's recommendations.

Just as the browser is permitted to display URL-2 in the location bar  
and the html body, OpenID discovery should be permitted to define and  
use a new entity as it sees fit.

In the end, it boils down to your expectation / assumption that the  
User-supplied ID should also be used as the Claimed ID; the OpenID  
spec defines the Claimed ID in a different way, in a manner that does  
not violate the HTTP RFC.



Johnny