[OpenID] Temporarily redirecting one's identity?

Martin Atkins mart at degeneration.co.uk
Sat Jan 6 13:35:50 UTC 2007


Martin Atkins wrote:
> 
> I believe that the spec doesn't make any distinction between permanent 
> and temporary redirects: any kind of redirect serves as a 
> "canonicalization step" (so, for example, 
> http://www.livejournal.com/users/frank/ becomes 
> http://frank.livejournal.com/) and so the ultimate destination URL is 
> used as the claimed identifier. (In other words, LiveJournal is "wrong".)
> 

I don't know why I didn't realise this when I was last replying, but the 
reason for the inconsistency between LiveJournal and the JanRain library 
is that LiveJournal's RP is still using the 1.1 protocol without Yadis, 
so it's seeing your <link rel="openid.server" ... /> and thus never 
seeing the redirect to the XRDS document. The JanRain library has been 
updated to prefer Yadis over OpenID's own discovery.

Really there are two sets of rules in play here. OpenID (without Yadis) 
says that the claimed_identity is the result of following all redirects. 
However, when Yadis is in play the discovery part of OpenID is not used 
and the claimed_identity is (presumably) the URL at which Yadis 
discovery succeeded. The successful Yadis URL needs to be defined by 
Yadis. However, I can't actually see anywhere in the Yadis spec that 
defines RP behavior when a redirect is recieved.

So this behavior is (unless I'm missing the key part of the Yadis spec) 
undefined in the Yadis case. It might be a good idea to define this in 
an errata while we still only have a small number of Yadis 
implementations to worry about.

Here's some proposed, rough descriptions of what should happen:

== Permanent Redirects ==

When a 301 Moved Permanently response is recieved, the Yadis user-agent 
MUST re-attempt the request at the new URI identified in the Location 
response-header, and MUST use the new URI as the Yadis URL for the 
remainder of the request.

Relying parties MAY, if it is practical and desirable, migrate any 
existing data relating to the original URI to instead be related to the 
new URI. A dependent service MAY, at its option, require such behavior 
for RPs making use of that service.

== Temporary Redirects ==

When a 302 Found, 303 See Other or 307 Temporary Redirect response is 
recieved, the Yadis user-agent MUST re-attempt the request (with the 
behavior defined in the HTTP specification for each respective response 
code), but MUST NOT use the new URI as the Yadis URL. That is, the Yadis 
user-agent MUST request the new resource but act as if the result had 
been retrieved from the original URI.

Relying parties MUST NOT migrate any records or data relating to the 
original URI to the new URI.

== Chains of Redirects ==

It is acceptable for a request to pass through more than one redirect as 
defined above before the Yadis discovery ultimately succeeds. The Yadis 
user-agent MUST process each redirect as a separate case as per the 
rules above, maintaining through out the correct resulting Yadis URL 
based on whether the redirects are temporary or permanent.

The Yadis user-agent MAY refuse to follow an unreasonable number of 
redirects. In this case, the Yadis user-agent MUST consider the request 
to have failed and the Relying Party SHOULD provide suitable feedback to 
the user.

------------------------------------

The language certainly needs cleaning up, but I think these rules are 
reasonable. These are essentially just extrapolations of the behavior 
defined in the HTTP/1.1 spec. Can anyone think of anything I've missed?

It's probably also mentioning (by reference alone, since we're not 
modifying the behavior) that normal HTTP mechanisms such as 
If-Modified-Since and If-None-Match can be used as defined by HTTP for 
caching purposes.




More information about the general mailing list