cachability of delegated identity URLs

[Brad Fitzpatrick]

On Thu, 9 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > 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.
>
> I don't like it, and I think it's a small minority of consumers that
> will need this.  Most consumers will start by creating a cookie-based
> session for each user, and store things like this in there.  When the
> reply comes from the server, they'll already know what the user was
> trying to log in as, and what reply they need from the server to let
> them in; they won't have to look anything up in a cache, it'll be right
> there in their session.   Other consumers could explicitly set it in a
> cookie, and look it up when they get their reply.  Those few consumers
> which really do need it in the GET parameters the server arranges for
> them to have can very easily put it there themselves; the spec makes it
> very clear that they have that option for anything they need to
> remember.  I think best to leave it out.

I started to strongly argue in favor of protocol support, mostly arguing
along the lines of it makes the bridge between all the languages' OpenID
consumer libraries and web framework thicker, with more hooks involved,
and I didn't want people forgetting to define those hooks and delegated
identities becoming second class citizens only supported on N% of sites
out there.

But then your point about putting it in the return_to as a final resort
won me over.  My Perl module will do that if callers don't define/override
any of the cookie/session-based tracking methods.  (which won't be
supported soon.... I'll start with just adding it to the return_to URL)

Consider me convinced.

- Brad