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

[Manger, James H]

> and what are those semantics for a 301?

301 MOVED PERMANENTLY
The user is no longer using this URI as their OpenID,
they are using the new URI (from the Location header) instead.
The RP should restart OpenID discovery using the new URI.
If the RP has existing records linked to the old URI it would be convenient
for the user if they were changed to use the new URI.

307 TEMPORARY REDIRECT (or 302 FOUND)
The user is not using this URI as their OpenID at the moment,
they are using the new URI (from the Location header) instead.
The RP should restart OpenID discovery using the new URI.
The change is only temporary -- the user might use the old URI as their
OpenID in future -- so the RP should not change any existing records
mentioning the old URI.

303 SEE OTHER
The request has succeeded -- this is the user’s claimed id.
The discovery data (XRDS, OP address…) for this claimed id can be collected
from the URI given in the Location header.
The RP should use the old URI as the claimed id, and
perform a GET on the new URI to find the OP details.


> That a website or some proxy gets to claim to an RP
> that one's permanent openid has been permanently re-provisioned?

> Of course it hasn't.

Of course it has!
The only website that gets to say your OpenID URI has been permanently
re-provisioned is the website hosting your URI. Why would your OpenID URI
return a 301 Moved Permanently unless you wanted it re-provisioned?
The only proxy involved is any proxy the RP uses (not a proxy in front
of the user’s browser). If the RP uses a crazy proxy, just like if the RP
uses a crazy DNS resolver (or trusts crazy root certs), then the RP might do
crazy things with its users accounts. This is standard OpenID, irrespective
of redirect behaviour.
 
> What is supposed to happen - the user input in the state vector of the RP
> changes, due to a 301 redirect? so the "permanent" value is shown as the
> user's openid once openid auth has completed?

Yes, (though I am not sure what you mean by “state vector”).
 
> Surely not. But that is what following HTTP resource-centric semantics
> would mean.



________________________________________
From: Manger, James H
Sent: Wed 3/5/2008 4:48 PM
To: general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)
Earlier emails on this topic:
1. [Jan 2007] Temporarily redirecting one's identity?
   http://openid.net/pipermail/general/2007-January/000946.html
2. [Nov 2007] "303 See Other" should not change Claimed ID
   http://openid.net/pipermail/general/2007-November/003681.html

The 2nd of these emails makes exactly the same argument as Noah,
with a few other wrinkles. It was ignored :-(

The 1st, by Sam Ruby, provides a use-case for using redirects
but not changing the claimed id.

My guess for why OpenID does not obey HTTP 303 semantics is simple
oversite. The semantic distinction between 303 (See Other) and other
redirects (permanent or temporary: 301, 302, 307) was probably not raised at
the time the text was written (in OpenID 1.x or Yadis?). After that point,
a fix is not backwardly compatible; it adds a little complexity to code;
and is not crucial for the use of OpenID. As a result a fix has not
garnered enough support from an editor to make a change. There is
considerable resistance to change when the authors are trying to finalize
a spec, and probably even more resistance after it has been released
(eg now).

I would still like to see a fix. I suspect very few existing OpenIDs use
303, and those that explicitly chose it are likely to want its specific
HTTP semantics.

James Manger
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general