Thanks for bringing this issue to our attention Tom, and for proposing its
resolution. This refinement has been added to the -26 draft.
-- Mike
-----Original Message-----
From: Tom Yu [mailto:t...@mit.edu]
Sent: Thursday, July 10, 2014 2:06 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Leap second ambiguity in JWT-25 (Re: I-D Action:
draft-ietf-oauth-json-web-token-25.txt)
Mike Jones <michael.jo...@microsoft.com> writes:
> 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)?
Hi Mike,
My reference for Seconds Since the Epoch in IEEE 1003.1-2013 is
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
I believe there have been several technical and editorial corrections to that
section of POSIX since 1988, so a more recent citation might be appropriate.
As far as I know, there is no RFC containing a specification of the POSIX
Seconds Since the Epoch definition. I think there is also no RFC that gives
general guidance on the handling of leap seconds when protocol time stamps are
represented as a number of seconds elapsed since some epoch.
http://www.eecis.udel.edu/~mills/leap.html (and to some extent, RFC
5905) provides a description of what happens with leap seconds in NTP.
RFC 7164 provides a useful and generally applicable contrast among behaviors of
official UTC, typical POSIX implementations, and NTP (even though the nominal
subject of the RFC is the interaction of leap seconds with RTP).
> 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. RFC 7164 shows how there is additional ambiguity of time stamps at the
sub-second level. I suspect that this does not have significant consequences
for most use cases of JWT. You might or might not want to mention that there
will be some ambiguities or anomalies in time stamps near leap seconds, but
that they will not have serious consequences for most applications.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
