Once more, LJ valid_to timespan.
mart at degeneration.co.uk
Fri Jul 1 14:12:31 PDT 2005
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
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)
More information about the yadis