Problems with OpenID and TAG httpRange-14

[Johnny Bufu]

On 20-Mar-08, at 4:40 AM, Noah Slater wrote:

> On Wed, Mar 19, 2008 at 08:59:24PM -0700, Johnny Bufu wrote:
>> Yes, it is.
> [snip]
>> The new claimed_id URL is the address of the discovered information
>> (which is of interest to the RPs in this case).
>
> No, it really isn't.
>
> Your argument, as far as I understand it, is that HTTP redirects  
> imply the
> original URI has an identity relationship final URI. You are using  
> the example
> of the address bar in a browser to illustrate this, i.e. "I type in  
> X and
> eventually it changes to Y, so X must equal Y."

Not at all! My argument is, rather:

"X and Y are two different things, with two different meanings. If  
the browsers are allowed to use Y as they deem appropriate, there's  
no reason why OpenID discovery can't do the same."

Where the semantic defined by OpenID for X and Y is:
User-supplied ID: X
Claimed ID: Y

And by the browsers:
URL typed in by the user: X
address of the displayed response: Y

> This is of course false, as explicitly stated in the HTTP  
> specification:

It would be, if OpenID said that User-supplied ID must take the value  
of Y.  Instead, it defines a new entity (Claimed ID) and assigns the  
value of Y to it.

I'm arguing that this assignment is not under the scope of the HTTP  
spec, and haven't yet seen an explanation of why it would be. This  
part has to be explained before quoting from the HTTP spec.

I also see no flaw in the above parallel with the browsers. Your  
argument seems to give browsers different privileges than to OpenID  
discovery, and I fail to see a good reason for this.


Johnny