Once more, LJ valid_to timespan.
kris at bbridgetech.com
Fri Jul 1 10:07:38 PDT 2005
I happen to like the way Brad et al. have set livejournal to 60
seconds, and his original interpretation.
If you take a look at LJ or any other consumer, you'll see that even if
it was set to a longer time, it really wouldn't matter. Why? Try
logging in. As long as the user is allowed to save a cookie on
livejournal.com that will enable him or her to login forever or just
until the browser closes, what you said doesn't really take any
precedence besides "re-authing". Although, if our interpretation says
that this is only an allotted time for the login process, that whole
issue drops-out completely.
Quite frankly, the generation of associate handles and keys are so
cheap that why not set the time low? This is better security wise
because every time someone wants to login, they are given a new
assoc_handle and mac_key/dh info.
The downside is one that if one logs-out of their ID server, what
ends-up happening is that they are still logged into the consumer.
Here's what I recommend:
On Level9's WebKit, after we have extended to a site that xyz user is
logged-in, if xyz user decides to log-out of any Level9 WebKit service
or <mylevel9.com>, Our servers will go to each site and tell the sites
that xyz user has logged out. We do this via XMLRPC, but it could
easily be implemented via http-post. We need a mode that logs users
On 2005/07/01, at 9:54 AM, Carl Howells wrote:
> Once again, I'd like to bring up LJ's openid server's return valid_to.
> It's still set only one minute in the future. I believe that shows a
> misunderstanding of the spec, and should be corrected.
> As I understand the spec (and others have agreed with my
> interpretation), the valid_to date is NOT how long the user and
> consumer have to complete the login process. Rather, it's how long
> the server is allowing the user to stay logged in to the consumer
> Having the valid_to time set at only one minute into the future is
> awful. It requires all spec-compliant consumers to re-authorize the
> user every minute. This is really strange behavior on the part of an
> openid server, as it guarantees that it will constantly be hammered
> with checkid_* requests from consumers that have followed the spec.
> Please up this to a more useful value. An hour seems like the
> absolute minimum useful time. A day sounds like a reasonable choice
> at the low end. A week doesn't seem unreasonably long.
> I know we're not the only ones who've run into this and thought it's a
> very strange decision.
More information about the yadis