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

George Fletcher <gffletch@aol.com> Wed, 25 March 2020 17:54 UTC

Return-Path: <gffletch@aol.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 8FC883A09DE for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 10:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.56
X-Spam-Level:
X-Spam-Status: No, score=-3.56 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, RCVD_IN_MSPIKE_H2=-1.463, 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=aol.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 XwiJeO_er30S for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 10:54:02 -0700 (PDT)
Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146]) (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 612333A091D for <oauth@ietf.org>; Wed, 25 Mar 2020 10:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1585158840; bh=5Ka/BQ8ue9gnsA2hox5CjXsRrxZzs8eR+nqxNHC4to8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=BCivkmrMMUf1CCLKlqhCyQR1jV13QwlwSsm4NuWnh3SCTRTzmzM/MFpT/26Meuwl4rnEpvxx9tEinBty9KePuoUWEXRidFHgYnNTsJkw451C+NRRueCozu6dOOMEoNy8cmvTxr/nXfwGMiJJyI2fbTDERWumqlfeNKeGjFxxydrkUnYm/t1EFUtx6d5GNjoUQI2zy9Bc4qZz8e63vT4tZWNlKh5jgUpman5FBYYvNOgClicvAGHp0dypJcJp62uqwADy6BTUtrx/dc90VJ6dz1w5fCAIxsZetutaGLxM0EawmNXrEE2WG2Kc0V+50E7svesLSvPidwtDpsMdxM287Q==
X-YMail-OSG: IHp3hokVM1m1WeJmTdxueL3BdEWj.AR8B.NYHZ3aux5YBOHf2hZJqlxaLRE_yr9 PAOjyXdH18gwJNAfTB5XydJAL9I22q2kNzf7H0UXNHJ6Q4oOY76uAtrmA_VcgwUpi0BzuGCdBC63 Rr7y2eUs_i7dE5h9hLKqBeLF9DUw9DyRjDbtVjdo_4KEgO0MlMIQezBdFoSACdg6NTTf7BLvohIu Y4am1zxUdDN45yNige_1oaRbjtQmQFldakUMTiSlzDYZInfw8aulosQsWy0h20Jd4YngsKdPHcn8 .xP_sJKFgBHMWIeJ_YP1WkF9WU9Whfp_ZG_vwwxx.wlvG.1IANRkNVp.4ap50xS_tDfkbpro0SqQ QmkjrZPPOfh5bNpm3d9i6lfbx481oeeWFcPzDdmkcSdgjoH_p7NRXkuQWHAuYmq1SXF8X0Ai.0Dr kclfUaf1Z1cN1DggwAaT01NEmuWqnQlrXMsHt9XtuaNle4t7CUrmw3i0RRIqluPBR.a4TdV557zT TO5CdWPofpU1nEDnalMk87IfHXDMRerpmH8GG90zQadyO7VqYsTi1zA9cAJo0eDwgjPoQlt1R2DX pyDLS4uLeaImjJFs1KV5T10GxDtwq0OnhQB4PwjG50EXdIn4JzPOKQPAaBmUMKvdL4Bbh8I9pwMs 1L_AiZ8d_dfbzYAZ6ppvfH4sUUVmjpvXuKc6CoJw3eFmAfWqGQW_vT.9S678ZUIL6OR_SNasViqm XHrBR3au.a.hSh8I_I3jmrL_UTKe3kcsLAMNR3h3d1dV4mFnMaBKUCN8WpI4p8ZVC4gWxIfQkDys i0pp9m2KbeB4NpHSCKfY4Tw2V4GKaCjA8HdPm7KLKkvBka188_lpuc1yqJnJFUeKsMuhCzC88zFt zGahJX3Pa3vvD2mSfEqO5Mxb8o2.gC6lHLGJiDFjClcpFrhQu1BtEltF53LjFoPAkYHXDYp0hKKt HKe_pPYVJyf7YF46pKX.TVrnbe6v1H4rWKo3QyZelHsKrJY12soW_gr8Hfr6H0xUXdDOMtI07Lxw X3eXLEabyDn3jMm88x2I7V6v6NqTyr4YU2QFWuK8_i6hDbpJUqAG7RjartlqcCr224lKFx5veg.h 9ucISqpKisQ7EXJLUiRC4fSmcrp6vEWk22_sjLbNSLAA.s6NWMAGcj40cSjEwHN7IkFKAUF7Zuui p1i.jf._SgBBUTd7aYer3jVqEPLMpIUmVavvUbS6lHfFMHl5BUYR22HEkYYNMaA0_ZUxY8fD_bzP EXQvDl0DWWngLPU7nNTrNDDqatFurPkfZR1xkLAzQR2EXe6pfOjfc_eErvg7sKrMzhN09K83szlu JosW96iCXdJmBUrwP0B3cWBvQ9VQ7l2MFWzoGSLsKVXTI5jf7weXubiyzdK.HCi4wXNcNmWl_8ZH YC53_RQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 25 Mar 2020 17:54:00 +0000
Received: by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7d4f9e74f3c4a0353f1b2a3c96540975; Wed, 25 Mar 2020 17:53:58 +0000 (UTC)
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>
Cc: 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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <a0842eb4-582b-59ab-855d-8e48828e92ee@aol.com>
Date: Wed, 25 Mar 2020 13:53:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCSTKNMchR_20z7VRi1XS+kkzi3+8ey_+hB7bK-onRv2Bg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------97A5573F44AFFF81C2767CA1"
Content-Language: en-US
X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/biO1TPOz3jW_DrTpHForsK1HVI4>
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 17:54:08 -0000

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> 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 <bcampbell=40pingidentity.com@dmarc.ietf.org>
>> *Sent:* Wednesday, March 25, 2020 8:48 AM
>> *To:* Vittorio Bertocci <vittorio.bertocci@auth0.com>
>> *Cc:* Richard Backman, Annabelle <richanna@amazon.com>; oauth <
>> 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> 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
> https://www.ietf.org/mailman/listinfo/oauth