Once more, LJ valid_to timespan.

[Martin Atkins]

Brad Fitzpatrick wrote:
> 
> I don't think the OpenID server should dictate it... the user should
> choose when they log into their next site.
> 
> LiveJournal, for instance, lets people choose between "this browser
> session" and "forever" (which requires them to log off at some point).
> 
> So I'm bound to either ignore valid_to on LiveJournal, and/or set my
> OpenID server's valid_to to like 1 month.
> 

I think the intention of the valid_to field is to allow the ID server to 
say "I vouch that this person will be bradfitz.com for the next five 
minutes. After that, I have no idea."

This has always seemed a little odd to me, but I just figured you'd set 
it to expire at the same time as the session you have. LiveJournal's 
sessions have an expiry time, so you'd just use that. I don't remember 
how the "Forever" mode is implemented, though; I'm guessing there's some 
kind of automatic session renewal going on in there.

My brain is wandering towards some kind of automatic (as in no user 
intervention) session renewal, but I can't really think of any 
implementation of that which wouldn't either introduce security problems 
or just generally be a pain in the ass to do. (You'd end up doing an 
OpenID redirect circuit before loading a page, or something.)

So in practice, I can't really think what the valid_to is good for. It 
would be better, I think, to just make it explicit that you must log out 
separately for every site you're using. Presumably many consumers will 
use the tactic of expiring sessions where it hasn't "seen" the user for 
a while, while others will have a particular expiry time, and others 
won't expire at all. Of all of these, only the second is really 
compatible with valid_to, and consumers being bolted into existing 
applications can't be expected to radically change the session management.