Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-25.txt

From: [email-masked]
Date: Fri, 04 Jul 2014 15:38:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

        Title           : JSON Web Token (JWT)
        Authors         : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-25.txt
	Pages           : 32
	Date            : 2014-07-04

Abstract:
   JSON Web Token (JWT) is a compact URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JavaScript Object Notation (JSON) object that is
   used as the payload of a JSON Web Signature (JWS) structure or as the
   plaintext of a JSON Web Encryption (JWE) structure, enabling the
   claims to be digitally signed or MACed and/or encrypted.

   The suggested pronunciation of JWT is the same as the English word
   "jot".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-25

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Yu <[email-masked]>
Date: Mon, 07 Jul 2014 18:19:57 -0400

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.

---

From: Mike Jones <[email-masked]>
Date: Thu, 10 Jul 2014 02:18:12 +0000

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-masked]] On Behalf Of Tom Yu
Sent: Monday, July 07, 2014 3:20 PM
To: [email-masked]
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

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

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Tom Yu <[email-masked]>
Date: Thu, 10 Jul 2014 17:06:20 -0400

> 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…

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 th…

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.