Once more, LJ valid_to timespan.

[Martin Atkins]

Brad Fitzpatrick wrote:
> On Fri, 1 Jul 2005, Nathan D. Bowen wrote:
> 
> 
>>Carl Howells wrote:
>>
>>
>>>So, it looks like the entire purpose of the issued and valid_to fields
>>>was to give the ID server some way to specify when the user's login to
>>>the consumer should expire.
>>
>>I thought the purpose of valid_to was to ensure that an identity
>>response will not be used to *initiate* a log-in after the response
>>reaches a certain age.
> 
> 
> That was my impression too.
> 
> And even with AJAX mode, the server gets it within seconds, then binds it
> to that user's existing consumer-side-based session.  It doesn't even
> matter how long the comment takes to write.
> 

One case that valid_to breaks is my guestbook app, which retains no 
state but instead just does the OpenID validation step twice. The first 
happens immediately, but the second happens once the comment has been 
entered and the form submitted, which is likely to be more than 60 
seconds later.

Of course, the guestbook is totally vulnerable to replay attacks. The 
message isn't included in the URL and thus doesn't get included in the 
signature, and because there's no state it can't track which signatures 
it's already accepted and shouldn't use again.

The easy answer is to just say that consumers have to be able to retain 
*some* local state, but I think that's a cop-out. A guestbook 
application is not security-critical enough to matter in my opinion, and 
it would make the code a lot more complicated than it already is. I'm 
sure there are lots of other potential applications with similar 
requirements. A guestbook isn't unlike a simple flat set of blog entry 
comments on a site which is otherwise based on static HTML: the comments 
component is likely one of the few parts that's dynamic, and so it'll 
want to be as simple as possible: just shove the new comment on the end 
of a static file and have done with it -- exactly what my guestbook 
does. (though the comments app would likely at least attempt to do some 
locking to avoid a race condition with two concurrent requests)