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

Jared Jennings <jaredljennings@gmail.com> Tue, 12 May 2020 03:14 UTC

Return-Path: <jaredljennings@gmail.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 BE0653A0966 for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 20:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 40QOjkKX1K9N for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 20:14:34 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6A03A0956 for <oauth@ietf.org>; Mon, 11 May 2020 20:14:34 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id b6so11124301qkh.11 for <oauth@ietf.org>; Mon, 11 May 2020 20:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=c5Ur1ziVec+PQhHOPVN+H7zAfE5c0d7iHp5C0Kjo2qY=; b=GookgpnyZoZlnR98mSjxzWGZt9TAMaxknZ/OVN0drF5b6QCP4mi9nd7G+iknS8gp7H y3V32AlpFzY9BI9Adyeh9ps1rZR37dwQvx2Qe4WmsaAOJ6oCiItlo02dJgsxzEfdlQlO ZLvaudw1bmaMH/SJNZzdXL1WJYNrBR0mAdFALn2y4a5Lb/tboS2i6m9jYIPnmNGVnpra eavG/n98pja3FHZlDgzgkEsplu/7x6O2E/mMRXW9ZRI5AEkCqwm0zLP0TzxwqWILHQYL ezV8vi/2R9K5C9nf6KuPt1PZmdil4RljE2n962dpSxgg2qECWhJP6yRNVsePZFo9tpwP qkTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=c5Ur1ziVec+PQhHOPVN+H7zAfE5c0d7iHp5C0Kjo2qY=; b=VsTkhJUD4aT0P8SW2Cp+0mibi7huYL4Xg8PaKifhPD3R14E6IXv8uNvz2lRcW7f4vY 1xjHdUjMPcZ8OrzwrtvtOCa27f5nMRGv2cztinZr2StXXg3gFCk8N07KHJuOZaoVGFW3 UHFGCpmc2u8WCJvh4MvNYFbkQfWwebyEr8YqVvu1pMUcWATHumhLsJeWL4eRVe9XprSC k1O2deZa5O3hVqTnbHeoHNO8wcN0ycss9YXZTuH1D1A4Px58jwkKoigMZ2E2FLhsr4Tj cyL9Wy6c3sols5xOS7liGZYy1OuXtT7SApKKbapFB8SF+BzSCLBFMQ7CHeax0hAB5n/z i9NQ==
X-Gm-Message-State: AGi0PuaJCEf2D62dFIFp0s34cuE3my3VBa/LnDsyOjCfL7UpjEWNBqax uO22W+AXXF3UWFtu1qXqO2g=
X-Google-Smtp-Source: APiQypLxdkGmVxZzjFMCK+DcUPhlIXxtWgnwrVoxN30X+RU26yD2f92n1/XJsCa6oTLyZyAKoggx9Q==
X-Received: by 2002:a37:dc6:: with SMTP id 189mr7653213qkn.279.1589253273152; Mon, 11 May 2020 20:14:33 -0700 (PDT)
Received: from jareds-mbp-2.lan ([72.214.174.119]) by smtp.gmail.com with ESMTPSA id j36sm10462643qta.71.2020.05.11.20.14.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 20:14:32 -0700 (PDT)
From: Jared Jennings <jaredljennings@gmail.com>
Message-Id: <CA4B872F-C0A1-4011-9221-B27CB45C41AB@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_19CF74DC-52E5-4C24-A6A6-DD9E6F26F168"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 11 May 2020 22:14:30 -0500
In-Reply-To: <MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com>
Cc: Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>, "oauth@ietf.org" <oauth@ietf.org>
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0@MWHPR19MB1501.namprd19.prod.outlook.com> <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr> <CAMVRk+Ln4xo_3pC6ALf0rp3+7gHyvO1zV=+NsA2pW4AZJ=1JAw@mail.gmail.com> <MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pMUvzyA4zA6fiLCx3Ccf_gqmCpg>
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: Tue, 12 May 2020 03:14:37 -0000

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from making bad choices, not from a security perspective. Meaning, it's not a security risk that a client does inspect or analyze the token. Instead, it's is an interop issue and thus we are guiding implementors to never assume or expect the token format to be consistent or of a expected format, for various reasons. I kinda know the answer to this question, but I am kinda asking this way to help restate the intent of the "topic" and maybe help guide to a wording that works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile or inspect an "Object", but at the same time knowing that such a method or practice should never be used in production.

Jared


> On May 11, 2020, at 19:24, Vittorio Bertocci <vittorio.bertocci@auth0.com> wrote:
> 
> Real world scenarios are full of situations where additional assumptions can lower dangers that must be taken in consideration in the general case, which might make less of a risk going against the specin those particular circumstances, but their existence doesn’t warrant relaxing guidance for the general case. A concrete example: I worked on scenarios where resource servers wanted to guarantee some degree of business continuity in case of AS outage, which boiled down to RS’ willingness to accept ATs past their declared expiration time, on the condition that the AS outage condition was detectable and the staleness of the AT didn’t cross a tolerance threshold. The business scenario made sense, and the implementer was within their right in deciding that disregarding exp in those circumstances was acceptable. Nonetheless, I would not argue that given the existence of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.
>