Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Mon, 20 April 2020 08:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E41AB3A08E1 for <>; Mon, 20 Apr 2020 01:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oMorxuqtieiH for <>; Mon, 20 Apr 2020 01:11:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AC643A046D for <>; Mon, 20 Apr 2020 01:11:00 -0700 (PDT)
Received: by with SMTP id y25so4583102pfn.5 for <>; Mon, 20 Apr 2020 01:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=tcxHdrW5igwdjhgkuRBznLolNnPgZwqzLP57hDM2X4I=; b=LZdZZpBgJwW79E3EpP1Fwx7ybWMYDEzMI/fKK1z9Pv2fTYcTgNF2Hpz4Cd0pEspbbZ LElECFcDriayyX5DYRlLeZ2D4BV2AQ7rsC3bduabJlSyKn4V9Tp48JYvAaUpXWpPj9s5 vDEWqwXVSzH8RffQh5CcwMj1PJee/hDqzlymnLFwru7CiCmXum1xUJtK/n0xUEEu77zC sDXk33tq9HwGuaOTZFVMyytGswKBlnnUKcFr0/oU7PUU1sZgXIbFOkGrLHC2PNatFsTs m9nN1TJcAefgYoPnyxltLUnK48b9c8EqD5DA73gi3w1cvTf3rjo/3o6ryvPZKOX+KiaM FFGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=tcxHdrW5igwdjhgkuRBznLolNnPgZwqzLP57hDM2X4I=; b=D0sTKjVxGyGqrLPNBn0WieoDlQmtpgWIYe6WvuztpuIxZvYnWKfkUn6R+duDPMpCQY 5BerUQNFYQv50j+BX+H9qoJBbk6Q+LZ1ptgJ613Cr4ISWGCEbeW1X+HjM1Z1Wmf3jEam JIAUfwMXEMnbV5SnTWrAAnTolkC7L7O7lQyZL0eJGIznG08B7n/wRVWFr9xN23Q3xz8O YVRcjwHc1T8qUKNFRJS8uRNzutyLI5s59llOVrFk8LDYowgYdi5K1bJ59CEOjddtzN7+ S8BYhrj9oGt/0aoBgcrrtPInCTgEGlX0FIMs8hk914aP52uuE6VrYy5nDatKlxyCwSOf EDwg==
X-Gm-Message-State: AGi0PuYyVW0lJzrMHbQ1Ripl903xaO/HMO+2DqKyFq4N8nQIEwqHyW8y rqH7K1N+7ook2sw/7Vk68s4J15Qk6TAniA==
X-Google-Smtp-Source: APiQypLEgv0nKI+UDbINujG5XHii4QphG+fv4VVpLhglVOcVg/JpsYAl623uvG2+Vpc3/rXvXB5h2w==
X-Received: by 2002:a63:514a:: with SMTP id r10mr13304365pgl.246.1587370259444; Mon, 20 Apr 2020 01:10:59 -0700 (PDT)
Received: from vibrosurface7 ( []) by with ESMTPSA id r128sm357267pfc.141.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 01:10:59 -0700 (PDT)
From: <>
To: "'David Waite'" <>, "'Vladimir Dzhuvinov'" <>, "'Dominick Baier'" <>
Cc: <>
References: <> <> <> <>
In-Reply-To: <>
Date: Mon, 20 Apr 2020 01:10:58 -0700
Message-ID: <08b901d616eb$392e2760$ab8a7620$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08BA_01D616B0.8CD19950"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMKsWrR7q68zM9CsrN/StHwRJR9eAIthgGoAs78VUYCJVShOaXfRoXg
Content-Language: en-us
Archived-At: <>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Apr 2020 08:11:19 -0000

Thanks guys for the commentary here.

I wasn’t too partial on the “time claim” type. I just went for “Iat” very much in line with Vladimir’s guess, it was quite empirical: 

*	it comes from OIDC, and for the usual consideration that existing logic used for processing ID_tokens will be partially repurposed to implement some of the validation steps
*	“nbf” appeared as the “time claim” only in AzureAD and IS, while “iat” appears in AWS, OKTA, Auth0 and again Azure AD, hence it seemed the common choice

The slightly more philosophical, but still empirical reason is that I haven’t observed scenarios in which the RS defers to the AS the decision about the starting time for the validity of the AT, the semantic of “nbf”, whereas “iat” simply states a fact about the token and it’s up to the RS to decide what to do with it, including applying nbf sematic. That’s a decision that can be easily enshrined as a default in an SDK without loss of expressive power.


I am not married to “iat” and if there’s strong momentum for “nbf” I am open to change it, however we are in a second last call and we just discussed “iat” in the interim meeting last week, hence I thought we had pretty strong consensus on “iat” already. You folks tell me 😊


From: OAuth <> On Behalf Of David Waite
Sent: Sunday, April 19, 2020 10:00 PM
To: Vladimir Dzhuvinov <>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"


There are a number of ambiguities and statements around using JWTs in various contexts:


1. Some implementations interpret “iat" to also have the meaning of “nbf” in the absence of “nbf”, although this is AFAIK not prescribed by any spec

2. The DPoP draft’s client-generated tokens have the resource servers use their own nbf/exp heuristics around “iat”, since the tokens are meant for immediate one time use by a party that may not have clock synchronization.

3. There are recommendations in the JWT profile for OAuth that the AS may reject tokens based on an “iat” too far in the past or “exp” too far in the future, but not that “nbf” was too far in the past or that the interval between nbf and exp was too large.


The JWT spec also allows implementers to provide some leeway for clock skew. Presumably this meant validators and not JWT creators, although there is history of messages setting similar values to account for clock skew (e.g. SAML IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 minutes after issuance). 



On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov < <> > wrote:


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.

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.


OAuth mailing list <>