cachability of delegated identity URLs

[Brad Fitzpatrick]

Paul,

Continuing the discussion of <link rel='openid.delegate' ...>  Previously
I'd said there's no reason for the real identity (say,
http://bradfitz.com/) to go across the wire, since the consumer could just
see the delegated identity and work with that.

The problem is that on the return path, when the UA is redirected to,
consumer.com/login.app, then identity= field being asserted would be
the delegated one, say:  http://www.livejournal.com/users/brad/ and the
app would have no clue how to map that back to the identity the user typed
in (bradfitz.com).

The ugly solution is for consumers to put it in their return_to URL, and
have it outside the openid spec.  (or set it in that user's anonymous
session already created on consumer.com)  However, as it's something each
and every consumer would have to do in their own way, that's where I draw
that line at saying it should be part of the spec and given an "openid."
prefix.

So how about:

      openid.mode = "checkid_immediate"
      openid.identity = http://bradfitz.com/
      openid.delegated_id = http://www.livejournal.com/users/brad/

So then servers supporting delegation check first identity and second the
delegated id for matching.

But then it's openid.identity=http://bradfitz.com/ that's sent back in the
id_res mode response, so consumers can actually go refetch that identity
URL (from cache probably), find the openid.server link rel, and check if
they have an association, verify the sig, etc.

Cool?

- Brad