[OpenID] Temporarily redirecting one's identity?

Recordon, David drecordon at verisign.com
Sat Jan 6 23:33:39 UTC 2007

I'd be happy updating Yadis for this, though I think it will also mean
updating the OpenID Auth spec as well.


-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Saturday, January 06, 2007 5:36 AM
To: general at openid.net
Subject: Re: [OpenID] Temporarily redirecting one's identity?

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.

general mailing list
general at openid.net

More information about the general mailing list