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

vittorio.bertocci@auth0.com Wed, 25 March 2020 18:59 UTC

Return-Path: <vittorio.bertocci@auth0.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 42BF23A0BD0 for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 11:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 5dxAU5UNNehb for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 11:59:28 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 372243A0D86 for <oauth@ietf.org>; Wed, 25 Mar 2020 11:57:38 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id w9so1428717pjh.1 for <oauth@ietf.org>; Wed, 25 Mar 2020 11:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=pNytaNKZj1MYuY337UYWfOuMajtZKykgCBX7iO7Z1yk=; b=GsrwvxiqjBRl6osLnIltxAsGgQp2hi2FhzIEFkyvVzT6IwUJSNxiDqszLezWE7kG8Q 9K+cxf3M2CCTkqwlRVNCUOuZerahunVnRAfJldvk/YGGK2Du/8JpGCYC2pxWng2kD6di 5auF7aFNDiq5qOl84L5f9JPrLxojW0keeCin7n3ehdNRCmxyOlM6Fx0GRkl6vrnayLZi 1w/3VQEkv2wfa7sSZt8vHXAECoknvNShHoWhtS8AyXnpum/9gA1JpJ1esUSRoPCyXE5r JlyF816pavpf/ra636pUMLIxfBXABup40DjhifN1GqzSjGa1YbxZcO8LsSVOqT0lfxD7 Z+mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=pNytaNKZj1MYuY337UYWfOuMajtZKykgCBX7iO7Z1yk=; b=DY0d8Wr3P36nIu2oB4VUy0ZyhqhgEbi3Xj4oTEkaDJekmdu2cGL1c6d4IXVR0Y7hgN fUjXYSvSvvrQa+7Z77X6TyyGN+Cf0ZXk+isuR/ZGH77biUfsX+hz3j9KTEvTPh70j4YQ zb0xQ3fwoMWgMqTcIpV3In57dw8mvoVFTUKEK6nX2vnP0g4jR/HDImcGJWdMFe2A76R7 qG+Jdbmg+wRMgT5+wb4DC5dQRbbR3pF0EICQ04vAhCSXXmNGtEmkb6mVzwBxQhoFCuoq DwjsEgt0WvfnidCq3SOhpcGEfC5z1+igNLrBrJE2tQBkVoKzhqoXeiK/v76k8dl4V51i AbMQ==
X-Gm-Message-State: ANhLgQ0ncbZNZBe22JqpdOe/xdzxEM6mNtiUS3uqNI9FzlUHNZ1eBBda k5geXkCqmNwhWZeX9tL8wI7CtpQmJ1soW4U8
X-Google-Smtp-Source: ADFU+vuHqzrKyJQVvwFMl9i+GVIM0/xQmYmUT6Ride6Cb9eLVOM+psbt5E4biC3BHZEoKOEHGmtMVA==
X-Received: by 2002:a17:90a:aa86:: with SMTP id l6mr5452217pjq.30.1585162657110; Wed, 25 Mar 2020 11:57:37 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id c15sm17115823pgk.66.2020.03.25.11.57.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 11:57:36 -0700 (PDT)
From: vittorio.bertocci@auth0.com
To: 'George Fletcher' <gffletch@aol.com>, 'Brian Campbell' <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: 'Brian Campbell' <bcampbell@pingidentity.com>, 'oauth' <oauth@ietf.org>
References: <AM0PR08MB37160B8A021052198699CD17FAF00@AM0PR08MB3716.eurprd08.prod.outlook.com> <01ec01d6017c$162eb2e0$428c18a0$@aueb.gr> <CAHdPCmMzRn8iYG025Vq0sQNzgZTOkQJuMJwttDgjMDLESpjptw@mail.gmail.com> <CAO_FVe5UXY4Jxd3LdG6zyXJ8B8nFKYevcHQTVJEAFSdW0ku9tg@mail.gmail.com> <52f18114-4f8e-da86-5735-4c4e8f8d2db5@aol.com> <BL0PR08MB5394CA3CB524E95EA87CD6B6AEF10@BL0PR08MB5394.namprd08.prod.outlook.com> <74da4cc3-359c-c08a-0ae5-54c8ca309f32@aol.com> <D080BE8B-BD0D-4F63-9F33-BA23C2FB42DD@amazon.com> <DM6PR08MB5402639817677AD59898CD65AECE0@DM6PR08MB5402.namprd08.prod.outlook.com> <CA+k3eCS29X28CBXGiUtDAV8nceTcpfJ4Jr_x=E3x8_9crOqsOQ@mail.gmail.com> <13b6801d602c0$02ebea00$08c3be00$@auth0.com> <CA+k3eCSTKNMchR_20z7VRi1XS+kkzi3+8ey_+hB7bK-onRv2Bg@mail.gmail.com> <a0842eb4-582b-59ab-855d-8e48828e92ee@aol.com> <CA+k3eCQdQggPrVatvT2COrtEw2E4F2TTp_3uU6iSk1AsXeRwMg@mail.gmail.com> <13c4701d602d5$5990cdc0$0cb26940$@auth0.com> <29046ca9-71df-430c-80ec-8cf1700be0d9@aol.com>
In-Reply-To: <29046ca9-71df-430c-80ec-8cf1700be0d9@aol.com>
Date: Wed, 25 Mar 2020 11:57:36 -0700
Message-ID: <13c7701d602d7$403eccd0$c0bc6670$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_13C78_01D6029C.93E3C560"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHpUDYTHxkJVh4ssWS8Yidi1aurtgOePuTPAe6K2+4Cw7Q/fALxAaHcAhX/JksB9vfjsQIGwKg5AUrAuMkCKW1rtQHtHACQAbNjgnMDA9hCugIhXBR7AdRp8sIBtEvHGqcqT46A
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xChHdFyYS4j1ArRhBFyZ4A9kjKQ>
Subject: Re: [OAUTH-WG] 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: Wed, 25 Mar 2020 18:59:38 -0000

That works for me!

 

From: George Fletcher <gffletch@aol.com> 
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.bertocci@auth0.com; 'Brian Campbell' <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: 'Brian Campbell' <bcampbell@pingidentity.com>; 'oauth' <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

 

If we don't want to give guidance on how the RS determines the correct key to use to validate the token, then maybe we should state that explicitly. "The mechanism used by the RS to determine the correct key to use to validate the access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to specify how that happens.

Thoughts?

On 3/25/20 2:44 PM, vittorio.bertocci@auth0.com <mailto:vittorio.bertocci@auth0.com>  wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd behavior- for example, developers might see that you used a key for signing an IDtoken and use that for init all their validation middleware for ATs as well, say because the library only supports one key at a time, and then end up failing at runtime when/if the assumption ceases to apply in the future.
 
Would that be legitimate of them to take such a dependency, even without warning text? No. However I am not looking at this from the “lawyering up” perspective, but from the useful guidance standpoint as well. I am well aware that being concise is a feature, but I am also not crazy about making every specification into an intelligence test for the reader. If a 16 words sentence can help prevent a likely misstep, I’d be inclined to keep it. But if the consensus is that the sentence is confusing, I can also take it out.
 
 
 
Brian & George, in the spirit of keeping things simple, and given that this was more of a “just in case” warning rather than a security feature clamored for- if the language is problematic I’d be more inclined to take the sentence out rather than complicating the guidance further.
 
 
 
From: Brian Campbell  <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org> <bcampbell=40pingidentity.com@dmarc.ietf.org> 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher  <mailto:gffletch@aol.com> <gffletch@aol.com>
Cc: Brian Campbell  <mailto:bcampbell@pingidentity.com> <bcampbell@pingidentity.com>; Vittorio Bertocci  <mailto:vittorio.bertocci@auth0.com> <vittorio.bertocci@auth0.com>; oauth  <mailto:oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
 
 
 
I don't think you are missing anything, George (except that, to be pedantic, `kid` is a header rather than a claim). 
 
 
 
The question gave me pause, however, and makes me think that maybe the draft, with the aim of improved interoperability, should have some more explicit text about the use of the 'kid' header in a JWT AT and how it references the verification key in the content at the jwks_uri. 
 
 
 
 
 
 
 
 
 
 
 
On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:gffletch=40aol.com@dmarc.ietf.org>   <mailto:40aol.com@dmarc.ietf.org> <mailto:40aol.com@dmarc.ietf.org> > wrote:
 
Can we not use the 'kid' claim to inform the RS as to which key is being used? What am I missing?
 
On 3/25/20 1:51 PM, Brian Campbell wrote:
 
I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
 
On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=
40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>   <mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org> > wrote:
 
 
Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").
 
As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
 
 
 
*From:* Brian Campbell   <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org> <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org>  <mailto:bcampbell=40pingidentity.com@dmarc.ietf.org> <bcampbell=40pingidentity.com@dmarc.ietf.org>
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci   <mailto:vittorio.bertocci@auth0.com> <mailto:vittorio.bertocci@auth0.com>  <mailto:vittorio.bertocci@auth0.com> <vittorio.bertocci@auth0.com>
*Cc:* Richard Backman, Annabelle   <mailto:richanna@amazon.com> <mailto:richanna@amazon.com>  <mailto:richanna@amazon.com> <richanna@amazon.com>; oauth <
oauth@ietf.org <mailto:oauth@ietf.org>   <mailto:oauth@ietf.org> <mailto:oauth@ietf.org> >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
 
 
 
I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..
 
 
 
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci <vittorio.bertocci=
40auth0.com@dmarc.ietf.org <mailto:40auth0.com@dmarc.ietf.org>   <mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org> > wrote:
 
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
 
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the validation
section. That doesn’t mean this is useless, an AS might elect to use
different keys for its own purposes (eg separation of concerns for
forensics, different strengths, different lifecycles, and so on).
 
 
 
 
 
 
*CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly prohibited...
If you have received this communication in error, please notify the sender
immediately by e-mail and delete the message and any file attachments from
your computer. Thank you.*
 
 
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>   <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth
 
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>   <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth