Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Mike Jones <Michael.Jones@microsoft.com> Sat, 11 January 2020 00:41 UTC
Return-Path: <Michael.Jones@microsoft.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 0979912012D for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 16:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 quypq3F_kjuM for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 16:41:36 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650128.outbound.protection.outlook.com [40.107.65.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38886120120 for <oauth@ietf.org>; Fri, 10 Jan 2020 16:41:36 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OhU9DcKa0opGebfpdJrRhGoRMKmDx2w8/JXJgCctzXyTrC7wo80T2PNLL95bFsRNLba1J5pd5TKe5E6f2FIhfUIYKRicYDZxLbSiSRdNfkPtbIOakjY589ugiQMQ1x2xdjzSNwqa4krrvacOFIGWfDqa68m9US6cR229/88RMGrHaBzyKUO3QugU1r0IVD58/TeqywKkL1Waq1iETPw/qWPqL8Yi5EU+T9MYbpCrH5PVY79OGkV0pgD7xWLTQPAast8+QGqA5RzcovuNsNvs/yK1se6Vo878I1V4+YsQoSfcYPiR1Vwnvd4egt2mgesljV1bNR/KyZZUGtjBTtQW7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nKxQW0+L83LExBJIgI+zXpCz7TQs+Y/KcAvUL9NSD3Q=; b=IqepejVQyKJ/OuBdXfNw4xcdM/nUuAolNyWbOu4CAWONh3ZgRiFIJvu4JwSiE7XSAjTV2S2/StEO7uWZdHZipm1yHiqub5HNzMcD3ftsn4GOXcUkiHHViLAWy67wn8bWvsxVT7SuY/PSpBwOIEspe7ZqTqPkHG1jvY7J+X5mdekTIzof2/pEFcFO8Slpl6NWfP/q4fzE+A3AeaHXXeMPFoJdUIkuQ5f1z+TI2O2uRZnrx730hBYtCeM0LQIa7pS6jqyL2qeHKeYaFqSD48QKsKvp7+nTEoLkgvwDfxpcmEJFESvgWMDXX3A3mlDme2bvH4KDBpslerf2vJxYA3JHFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nKxQW0+L83LExBJIgI+zXpCz7TQs+Y/KcAvUL9NSD3Q=; b=D4yJ5Zfe0vdcJMHOiCQmwhI+HcLFnO4kDoL6wpUNf1lEjlBSsQemj4TfmWV9l6KFj+3s2L3CRION3Jd/AugLE2BsPrBFLbbW2YMytYhXEO9D8KDHQ6jGI1X5PJLO4OeXASma0iHRN3fBVoZH0qfcV5eRe94CNLaLyXi+/y1eyvE=
Received: from CH2PR00MB0843.namprd00.prod.outlook.com (10.186.139.150) by CH2PR00MB0780.namprd00.prod.outlook.com (10.186.139.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2669.0; Sat, 11 Jan 2020 00:41:33 +0000
Received: from CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::a116:aee3:2579:8104]) by CH2PR00MB0843.namprd00.prod.outlook.com ([fe80::a116:aee3:2579:8104%8]) with mapi id 15.20.2668.000; Sat, 11 Jan 2020 00:41:33 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Vladimir Dzhuvinov <vladimir@connect2id.com>
CC: IETF oauth WG <oauth@ietf.org>
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
Thread-Index: AQHVxFdFRSg/Wxr/G0+itQaCAzT9nKfePqqAgACvu4CABRMlAIAAA10AgAAOoICAACcyAIAAIu0AgAAF2QCAAA3QAIAADLEAgAAnlIA=
Date: Sat, 11 Jan 2020 00:41:33 +0000
Message-ID: <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com>
References: <fc3805e5-e908-00db-a734-990721371ab2@connect2id.com> <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com> <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com>
In-Reply-To: <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2317d277-ebe4-4204-b843-0000041a45d2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-11T00:36:15Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [50.47.92.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 38d10811-dfca-4dad-b741-08d7962f020a
x-ms-traffictypediagnostic: CH2PR00MB0780:
x-microsoft-antispam-prvs: <CH2PR00MB0780318BF9483243AC34CA62F53B0@CH2PR00MB0780.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0279B3DD0D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(136003)(366004)(396003)(39860400002)(199004)(189003)(26005)(86362001)(316002)(8990500004)(4326008)(7696005)(5660300002)(6506007)(53546011)(66574012)(9686003)(55016002)(52536014)(71200400001)(110136005)(2906002)(478600001)(76116006)(66476007)(64756008)(66556008)(66446008)(66946007)(10290500003)(33656002)(186003)(81166006)(8936002)(8676002)(966005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0780; H:CH2PR00MB0843.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4Urf/pJW3e88++tSS5/mHBNE5Nmrktz6Vw1SMs1W5NPo9tui6fzA7jqDvEp+Lc370y35KfAMPTFVAj9WnEY3JIQSs+qgpVh0T2d6SdooaJKOZjL5o9FmSBW1kQnJf1pV6cUI6fKfKxR5b6zSw0RKX+EsSfkrCV8u5s+P6G03byhI8hjRmYV+rx/FlMgEEnpEdhVVl0Uy0P/YiC5VPy0SBIz6Z9zYQGw1euNHeVPwjRZFyYVzUOW251lbIvH9SgPQK0nLN6aLa761RBSuqzjYg/lhEgU0keI56Ms68cfqsCMYjFe4ka5GzEjuthjqGjYEGOyJ/WG8cqyOV4KK78sFzvpMEKKO4rmAiYLB/xkwyYxzsP6CrUwyRdB3nBuHv82hH5DUH4ejT79ep/MOCEqmXwFFLnpstooTvne6vwufX6WHPbrGLmaQYOFCYJ/FBVL1wXXNLriCFc+E71rfFEUU5YRd8xPkekm9VGaLZtVPCNgFCFd9cInpUM+DrLcPOuShq7VmHaOE53sXW4W68nRdhA==
x-ms-exchange-antispam-messagedata: yN/tP+Vv48OVEkg/+/g5poEjgpT3S2siAJdqYDtcm0ajzEMe/m97jmh2w3IkzBStPlUdJd+sD5a9CplTkrdGcwh2cd5aT8hLWTxlX9euTYd93F/nEQfF0M0ah+J2Z4f4vIOu0MdmUn3uZ93DUwy55A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0CH2PR00MB0843namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38d10811-dfca-4dad-b741-08d7962f020a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2020 00:41:33.6666 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iGG4EjxbY0z9zG17cAlV+LvfvHdI9UVIjBxIOIENDORx0CR7fKwXvO7JTs0uvu1wWpuDqHMx9m5cvvJQdPqiKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0780
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GDAlt6_USwDK5L9vRoSBJElOERs>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
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: Sat, 11 Jan 2020 00:41:41 -0000
The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.) -- Mike From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley Sent: Friday, January 10, 2020 2:15 PM To: Vladimir Dzhuvinov <vladimir@connect2id.com> Cc: IETF oauth WG <oauth@ietf.org> Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object The intent was to do that, but specs change once the OAuth WG and IESG get there hands on them. Being backwards compatible with OIDC is not a compelling argument to the IESG. We were mostly thinking of asymmetric encryption. Specifying puting the issuer and or the audience in the headder has come up in the past but probably is not documented. John B On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <vladimir@connect2id.com<mailto:vladimir@connect2id.com>> wrote: Yes, putting the client_id into the JWE header is a way around the need to have the client_id outside the JWE as top-level authZ request parameter. Unfortunately this work around isn't mentioned anywhere, I just checked the most recent draft-ietf-oauth-jwsreq-20. Our DDoS attack mitigation (for OIDC request_uri) also relies on the presence of client_id as top-level parameter, together with requiring RPs to register their request_uri's (so that we don't need to build and store an index of all request_uri's). I just had a look at "DDoS Attack on the Authorization Server" and also realised the request_uri registration isn't explicitly mentioned as attack prevention ("the server should (a) check that the value of "request_uri" parameter does not point to an unexpected location"). https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0> To be honest, I feel quite bad about the situation with JAR we are in now. For some reason I had the impression that OAuth JAR was going to be the OIDC request / request_uri for general OAuth 2.0 use, as with other OIDC bits that later became general purpose OAuth 2.0 specs. I find it unfortunate I didn't notice this when I was reviewing the spec in the past. Vladimir On 10/01/2020 22:39, Filip Skokan wrote: > Vladimir, > > For that very case the payload claims may be repeated in the JWE protected header. An implementation wanting to handle this may look for iss/client_id there. > > Odesláno z iPhonu > >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <vladimir@connect2id.com<mailto:vladimir@connect2id.com>>: >> >> I just realised there is one class of JARs where it's practially >> impossible to process the request if merge isn't supported: >> >> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows >> for that and specs a method for deriving the shared key from the >> client_secret: >> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0> >> >> If the JAR is encrypted with the client_secret, and there is no >> top-level client_id parameter, there's no good way for the OP to find >> out which client_secret to get to try to decrypt the JWE. Unless the OP >> keeps an index of all issued client_secret's. >> >> >> OP servers which require request_uri registration >> (require_request_uri_registration=true) and don't want to index all >> registered request_uri's, also have no good way to process a request_uri >> if the client_id isn't present as top-level parameter. >> >> >> Vladimir >> >> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote: >>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>: >>>> I think Torsten is speculating that is not a feature people use. >>> I’m still trying to understand the use case for merging signed and unsigned parameters. Nat once explained a use case, where a client uses parameters signed by a 3rd party (some „certification authority“) in combination with transaction-specific parameters. Is this being done in the wild? >>> >>> PS: PAR would work with both modes. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- [OAUTH-WG] JWT Secured Authorization Request (JAR… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Dominick Baier
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … n-sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Takahiko Kawasaki
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Dominick Baier
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Jim Manico
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Brian Campbell
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Author… John Bradley
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Mike Jones
- Re: [OAUTH-WG] JWT Secured Authorization Request … Joseph Heenan
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … George Fletcher
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Rob Otto