[OpenID] Problems with OpenID and TAG httpRange-14

[John Kemp]

Hi Noah,

Noah Slater wrote:
> On Tue, Mar 04, 2008 at 10:25:15AM -0800, Peter Williams wrote:
>> I only normalized the user input.
> 
> The OpenID spec says:
> 
>   Consumers MUST canonicalize the Identifier URL, following redirects, and note
>   the final URL. The final, canonicalized URL is the End User's Identifier.
> 
> I think this clearly indicates that the URI must be canonicalised to "/about/".

I agree. That is the user's *identifier* (an identifier doesn't have to 
  have properties of a URL, it just has to identify the user)

> 
>> My SP openid engine does not know how many redirects (if any) are followed when
>> locating the HTML page.
> 
> No, but according to the spec you must replace the initial URI with the final one.

httpRange-14, and the associated HttpRedirections-57 
(http://www.w3.org/2001/tag/group/track/issues/57) discuss issues 
related to caching of content after following redirects, and also UI 
issues (ie. if the original identifier was bookmarked for example, or if 
a website shows a page from a different location than the one shown in 
the browser address bar)

These are all certainly issues, but for the purposes of using a URI as 
an OpenID identifier, what are the implications?

> 
> As I pointed out, though I'm not sure the references got through the HTTP RFC
> and the TAG httpRange-14 findings clearly show that is is incorrect behaviour.

I don't think it's incorrect to use the final, canonical URI as an 
identifier for the OpenID user. So in usage purely as an identifier, I 
don't think this TAG finding is relevant.

And if the content of the related page is an XRDS document you got by 
following redirects from the originally-provided identifier to the final 
identifier, then it would seem to me that the content of that is at 
least potentially cacheable - unlike any content you dereferenced from 
the original identifier.

A possible problem *might be* that the user might see content from a 
different location than the location shown in the address bar of their 
browser. That seems like a general problem with using redirects for 
protocols like this, and isn't solely linked to the "following 
redirects" part of creating a canonical OpenID.

Where do you see problems?

- johnk

> 
> --
> Noah Slater <http://bytesexual.org/>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general