[OpenID] Temporarily redirecting one's identity?

[Sam Ruby]

Martin Atkins wrote:
> 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.

I just checked my logs, and that is consistent with what I am seeing.

> == 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.

Be aware that "permanent" redirects aren't always trustworthy.  Example:

http://www.nevon.net/nevon/2005/04/rss_feed_hijack.html

> == 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.

Very nice.

- Sam Ruby