Thanks for pointing this out, Tom. I agree that we should use the POSIX
semantics. Other experts on the list - is there an RFC containing the
appropriate definition, or should I just reference my old POSIX.1 spec (IEEE
Std 1003.1-1988)?
As for whether IntDate must be an integer, the normative text says "no". It's
defined as "a JSON numeric value", which allows the values to be non-integers.
The name "IntDate" is misleading in that way. I'll try to come up with a
better name for use in the next version of the spec.
Thanks again,
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Tom Yu
Sent: Monday, July 07, 2014 3:20 PM
To: [email protected]
Subject: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action:
draft-ietf-oauth-json-web-token-25.txt)
Sorry for bringing this up so late in the process, but I recently had reasons
to read the JWT draft and saw the following definition:
IntDate
A JSON numeric value representing the number of seconds from 1970-
01-01T0:0:0Z UTC until the specified UTC date/time. See RFC 3339
[RFC3339] for details regarding date/times in general and UTC in
particular.
This definition is ambiguous with respect to the treatment of leap seconds. It
would probably be best to specify that this is a notional count of seconds from
1970-01-01T00:00:00Z, similar to the POSIX definition of "Seconds Since the
Epoch", which assumes that every calendar day contains exactly 86400 seconds.
I believe RFC 3339 gives no guidance in this area. It would also useful to
specify whether it's expected to be an integer; I might guess yes, because the
authors could intend "Int" to be an abbreviation for "Integer".
I have seen evidence that some system administrators see operational problems
with some protocols when they configure their systems to keep a non-conforming
variant of POSIX time that includes leap seconds.
(Interestingly enough, these involve a set of tzdata zone names that have a
prefix of "right/".)
If programs running on such systems transmit their non-conforming time_t values
by encoding them directly in IntDate fields, recipients may see illusory time
offsets representing the accumulated number of leap seconds (about 25
currently), even though the sending and receiving systems will likely agree on
encoded RFC 3339 UTC time stamps except in the immediate vicinity of a leap
second. It may seem like a small offset now, but I believe that it is expected
to grow significantly larger in the future, unless leap seconds are abolished.
Minor issue: the hour, minute, and second fields for the Epoch should be two
digits in RFC 3339 format.
Recommended new text:
IntDate
A JSON numeric value representing the notional number of integer
seconds from 1970-01-01T00:00:00Z UTC until the specified UTC
date/time, ignoring leap seconds. This is equivalent to the POSIX
[POSIX ref here] definition of "Seconds Since the Epoch", where
each calendar day contains exactly 86400 seconds. See RFC 3339
[RFC3339] for details regarding date/times in general and UTC in
particular.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
