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

David Waite <david@alkaline-solutions.com> Mon, 20 April 2020 04:59 UTC

Return-Path: <david@alkaline-solutions.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 C87223A0F93 for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 21:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com
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 susdGsoJWWUc for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 21:59:35 -0700 (PDT)
Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464CC3A0F91 for <oauth@ietf.org>; Sun, 19 Apr 2020 21:59:35 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 7F0DA3856D5; Mon, 20 Apr 2020 04:59:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1587358773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xMwDunGbKN5Gc7Y9830OnyQmN5nT0j9yXt4nAnwuYe8=; b=UKgTtZnT218N3bRH8SGtCVAWcT9SclAxsQMvULv4scyY/Z2eIGxJDoQppo51a6YqrDwHMN hpQyjgrrWDz9PiKwHfm0DfrhYetDTXd6iL9CkcKjAdPSrjhdi3WLqqwTn/kFqFR13ruaey 6MpKbHZjU6wNJFB1cfbbUsbDBFv/T0g=
From: David Waite <david@alkaline-solutions.com>
Message-Id: <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A999A5BC-6FCC-4243-9D9B-275A592E050A"
Mime-Version: 1.0
Date: Sun, 19 Apr 2020 22:59:31 -0600
In-Reply-To: <d9b766d0-75dc-926b-8c8c-951f1d5aface@connect2id.com>
Cc: oauth@ietf.org
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com> <d9b766d0-75dc-926b-8c8c-951f1d5aface@connect2id.com>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1587358774; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xMwDunGbKN5Gc7Y9830OnyQmN5nT0j9yXt4nAnwuYe8=; b=Qg2QxE2K5UJrD+DxPc5oPaDgqykfWeXh1gIbdU/6+J5sVvEwyx2BqAnBb31YEZHjQPTXVD cq8lawqJePqgrXSC2I49OL4mhp+MRjGu/9o0fZMTvdYIic7se9BUXXnvid8PnYBPDx3NTu RuyKzcrlWgyJsFiANspxlfG0tKlG4eI=
ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1587358774; a=rsa-sha256; cv=none; b=cus0FxJsPMsW1Q29IfPlnqK5PcEyzHcp5z5IHgng/V7ttIOM65m/7B1sU38d/4f21kmr8f Eb3U5mKlfItMnHssJvQw7Qqt7ijwuiKHHht2kfdql2ExiU0bS/RR7INKJx40Q1CUHCFRRU +iy1lY1znrEtTOLkP17PrMZS3ZbXyF8=
ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/MTIvi9xmn1GrSma9MkHVbPF1XwU>
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: Mon, 20 Apr 2020 04:59:37 -0000

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). 

-DW

> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> 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.
> 
> https://tools.ietf.org/html/rfc7519#section-4.1.5 <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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth