Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Vladimir Dzhuvinov <> Fri, 10 January 2020 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2F6612008A for <>; Fri, 10 Jan 2020 12:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5g9fP7Y206ig for <>; Fri, 10 Jan 2020 12:18:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65CF1120052 for <>; Fri, 10 Jan 2020 12:18:51 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id q0k4iGaJNdTTgq0k5iHlM3; Fri, 10 Jan 2020 13:18:50 -0700
References: <> <>
From: Vladimir Dzhuvinov <>
Organization: Connect2id Ltd.
Message-ID: <>
Date: Fri, 10 Jan 2020 22:18:48 +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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060502040600080708010403"
X-CMAE-Envelope: MS4wfO/v7oHLJfnZCn2Xc9Uo+Xvtw9EjKqlfZK1QUx4cUtyDMf3nkKsUl77xL2Br4KmabAxZtc5erNJIxioPPYfr9ndA3n0DNxVcz6vyFJJn0rXJbxzbpezP Ktkq2GaOo6F5JHJ3wEDAh5IeKcElEEh0b5oX1I4PhEFTD8k3fZV2qsBF
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 20:18:54 -0000

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

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.


On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> Am 10.01.2020 um 16:53 schrieb John Bradley <>:
>> 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.