Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 13 January 2020 15:57 UTC
Return-Path: <vladimir@connect2id.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 B34A3120811 for <oauth@ietfa.amsl.com>; Mon, 13 Jan 2020 07:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 A-015aFpH5l6 for <oauth@ietfa.amsl.com>; Mon, 13 Jan 2020 07:57:17 -0800 (PST)
Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (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 AF4BA12080B for <oauth@ietf.org>; Mon, 13 Jan 2020 07:57:14 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id r25XiNobiigqCr25Yi1nlU; Mon, 13 Jan 2020 08:57:13 -0700
To: John Bradley <ve7jtb@ve7jtb.com>, Mike Jones <Michael.Jones@microsoft.com>
Cc: IETF oauth WG <oauth@ietf.org>
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> <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com> <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com>
Date: Mon, 13 Jan 2020 17:57:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080403020503050708070400"
X-CMAE-Envelope: MS4wfJIckjzrkS36TvL1IduXeBAMUIrF0MMIpMZ1NOKmjAjK7A0ay4yhS6sokwOmcrjnUdBRSRfg5mjNM+7dQK0ttVLATaHAaXX3bMp49hWFD2nY6I4S6bhw qX/ZEERjA0wKqlUghoKNCz0Y3T56H6bvBaVSuutQ8UMnpSANuQMLjn1vrwBgCkTJYuLqe25nJY6czqBbz79uFYUghM+BAc1BxcqQIg2dbfVsMuiYZ8XFYoev UiiPNONVeI5PMPFse7hrug==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/oNswZUO7LmHYvH4cPqBPgpeyQ90>
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: Mon, 13 Jan 2020 15:57:19 -0000
John, thanks, much appreciated! On 11/01/2020 21:36, John Bradley wrote: > > Yes JAR is not prohibiting paramater replication in the header. > > I will see if i can add something in final edits to call that out. > > John B. > > On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote: >> >> Thanks Mike for the rfc7519 section-5.3 >> <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this >> parameter replication be used for client_id or the client_id ass >> "iss" even though it isn't explicitly mentioned in the JAR spec? >> >> On 11/01/2020 02:58, John Bradley wrote: >>> Right we just don't say to put the iss there in OIDC if it's >>> symetricly encrypted. >> >> OIDC doesn't have the symmetric key selection issue, I suppose that >> why the possibility to replicate params to the JWE header isn't >> mentioned at all. OIDC requires the top-level query params to >> represent a valid OAuth 2.0 request, and there client_id is required. >> If the client_id is present the client registration together with any >> present client_secret can be retrieved. >> >> I reread the JAR spec, this is the only place that mentions handling >> of symmetric JWE. >> >> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 >> >>> (b) Verifying that the symmetric key for the JWE encryption is the >>> correct one if the JWE is using symmetric encryption. >> >> >> Vladimir >> >> >>> >>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones >>> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> >>> wrote: >>> >>> 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 >>> <mailto:oauth-bounces@ietf.org>> *On Behalf Of * John Bradley >>> *Sent:* Friday, January 10, 2020 2:15 PM >>> *To:* Vladimir Dzhuvinov <vladimir@connect2id.com >>> <mailto:vladimir@connect2id.com>> >>> *Cc:* IETF oauth WG <oauth@ietf.org <mailto: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:// >>> <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