Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Vladimir Dzhuvinov <vladimir@connect2id.com> Sun, 19 April 2020 08:50 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D883F3A0872 for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 01:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.006
X-Spam-Level:
X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haXwRXcuEE-B for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 01:50:32 -0700 (PDT)
Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5993A0871 for <oauth@ietf.org>; Sun, 19 Apr 2020 01:50:32 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q5eojAy1FmDM7Q5epjjRYy; Sun, 19 Apr 2020 01:50:32 -0700
X-CMAE-Analysis: v=2.3 cv=At2QI91P c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=hlTvbsXRcvCjb8sc_2wA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=UbviTu1ZqzJtqA0RhU8A:9 a=t2uNApSflnAsOYvg:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <d9b766d0-75dc-926b-8c8c-951f1d5aface@connect2id.com>
Date: Sun, 19 Apr 2020 11:50:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020004030307010100040706"
X-CMAE-Envelope: MS4wfGu1tKUlYy7r/uLSxINmlRzEUAIPYaMc/r9jHe+hPpwuRhObf+Eiv4lmjwfSUM3t9+Jmpvkb5iKOdgVcHHdSWwxapr8V8oVSCXsMpZaifNQViiKDMLLv gUebOGDA+hrT3KmrWzB0Sk6B1I5t3gbxfXcOd2eKq916VTvHJsgwaR9I
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/p5OhnAqZQjip2ZxComGwLf7eH2o>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Apr 2020 08:50:34 -0000

On 16/04/2020 10:10, Dominick Baier wrote:
> *iat vs nbf*
> What’s the rationale for using iat instead of nbf. Aren’t most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir