Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

valid-until -> expires?

13 views
Skip to first unread message

Gervase Markham

unread,
Oct 18, 2011, 5:50:26 AM10/18/11
to
Should this page:
https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site
say "expires" rather than "valid-until" in the example return?

Gerv

Gervase Markham

unread,
Oct 18, 2011, 6:14:18 AM10/18/11
to
Er, and why is the browserid.org server sending responses with "expires"
set to the exact time the response was issued? Due to unavoidable
problems with relativity and the speed of light, I am unable to validate
responses before or immediately as they are issued, and so a direct
comparison between the expiry time and the current time will always fail...

$VAR1 = {
'email' => 'ge...@mozilla.org',
'status' => 'okay',
'audience' => 'bmo-4.0.localhost',
'issuer' => 'browserid.org',
'expires' => '1318932727587'
};

Returned time: 1318932727.587
Current time: 1318932731

Fail!

Gerv

Lloyd Hilaiel

unread,
Oct 18, 2011, 9:15:28 AM10/18/11
to Gervase Markham, dev-id...@lists.mozilla.org
Hi Gerv,

Apparently we overestimated the speed of light!

This bug is fixed in development right now: https://github.com/mozilla/browserid/issues/433

A temporary work around is to allow ~2mins difference from issue time and current time if you're verifying assertions, until this fix rolls into production next thursday.

lloyd

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

Brian Smith

unread,
Oct 18, 2011, 1:50:53 PM10/18/11
to Lloyd Hilaiel, Gervase Markham, dev-id...@lists.mozilla.org
Lloyd Hilaiel wrote:
> A temporary work around is to allow ~2mins difference from issue time
> and current time if you're verifying assertions, until this fix rolls
> into production next thursday.

2 min seems like an extremely tight tolerance. In NSS, we allow ~24 hour clock skew for timestamp checks due to mis-set clocks.

- Brian

Lloyd Hilaiel

unread,
Oct 18, 2011, 2:14:44 PM10/18/11
to Brian Smith, Gervase Markham, dev-id...@lists.mozilla.org
Assertions are signed using server time, so the unstated assumption is if browserid servers have broken clocks then we're screwed. Also if an RP wishes to locally verifying assertions, it must have a properly set clock. Client machines can be stayin' alive in the 80's for all we care.

At the point that we're doing completely decentralized assertion generation on the client we will have issues, but for now does this seem reasonable?

lloyd



0 new messages