Skip to content


Subversion checkout URL

You can clone with
Download ZIP


milliseconds or seconds since epoch #35

djc opened this Issue · 3 comments

2 participants


All JWT drafts so far have stated than an IntDate (the value for the exp and iat keys) should be in seconds since the epoch. The BrowserID (beta1) spec says it's ms since the epoch. This should be corrected; there should probably be a compatibility fix in the verifier.


Are you mostly concerned with the incongruity between JWT and BrowserID, or the inadequate highlighting of that difference?

I've been mulling over the role of mentioning the JOSE standards at all. We should definitely give them their due as inspirations for our data formats and as an aspirational goal later on, but for now, they're rather quickly moving targets. :(


I'm mostly concerned with the incongruity between JWT and BrowserID at this point, although given the incongruity as it stands, the spec should definitely draw more attention to it.

I guess I'm thinking about the JOSE standards (which actually JWT is not strictly a part of) about a 180 degrees differently: for me, they should be the standards BrowserID is built on, to make BrowserID part of the larger ecosystem using these standards. For one thing, the notion that some of the things in BrowserID are standardized and not just some funny thought out of some magician's hat makes me more confident that things have been thought out (that's my perception -- I'm not saying it's necessarily the case). For another, since becoming familiar with the JOSE standards through BrowserID, I've seen them crop up in other places, so I can reuse my code and familiarity with the standards.

Also, as I mentioned in the initial description of this issue, some parts of these standards have not actually been moving quickly. I did a little digging a few days ago and found that all JWT drafts so far agree on (a) the name of the "exp" key and (b) the type and unit of the "exp" value.

So while I agree in principle that it makes sense for the BrowserID spec to sit out some of the JOSE/JWT changes before adhering to the completed standards makes sense, I don't see that as a factor in this case (contrast this with the key names for JWK, for example, for which BrowserID is currently out of sync with JWK, but it looks like JWK might move back closer to JWK).


I'm going to WONTFIX this for the current version of the spec, but flag it with parity-jose for inclusion in our next data format update.

Prerequisite: Figure out how to version and update our data formats :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.