Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

Vladimir Dzhuvinov <> Mon, 20 April 2020 06:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF2E03A10E8 for <>; Sun, 19 Apr 2020 23:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 kotv6B00KukU for <>; Sun, 19 Apr 2020 23:12:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26CFC3A10E5 for <>; Sun, 19 Apr 2020 23:12:18 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id QPfDjbgT2b7cvQPfEjuqOQ; Sun, 19 Apr 2020 23:12:16 -0700
X-CMAE-Analysis: v=2.3 cv=O4lHQy1W c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=MXzmhXZ1gubhqf1ePBcA:9 a=QEXdDO2ut3YA:10 a=jGqiy6jZAAAA:8 a=c-ntgTk_fXaBXHuSi90A:9 a=ZqLJkzxFk54mY-CO:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=jHrLhlbFqA1ZHZAWynec:22
References: <>
From: Vladimir Dzhuvinov <>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <>
Date: Mon, 20 Apr 2020 09:12:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030808050702040103010200"
X-CMAE-Envelope: MS4wfCwjAnT8ms7ri5Ii4mUuKOMHCMBfSjsYH5hsTMUIXyh+BKLOUUyrMaBL2kKp9vz+OoaTNsPNEzC0pHglNCfDSoRDhe1hJPo+nG5+eqtLoKEaF+Ta42AM d0iycu8KbOPQX5alD1LQCTZcWC+4KYWqc8Cg+UE6V6RbqUwqTwaGZhTi
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt
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: Mon, 20 Apr 2020 06:12:20 -0000

Nat, John, thanks for updating the JAR spec. I just reviewed it, in
particular the authz request and the security considerations sections.
Choosing to make client_id (as top-level parameter) mandatory for all
cases, even for those when it can be readily extracted from the JWT,
makes the job of implementers even easier.

I have just one comment about the last paragraph in section 5, assuming
backward compatibility means with RFC6749 requests. Here is my proposed

The client MAY send the parameters included in the request object 
duplicated in the query parameters. For instance, this can be done 
to ensure the minimal required query parameters for an OAuth 2.0 
[RFC6749] authorization request are also present. An authorization 
server supporting this specification MUST however only use the 
parameters included in the request object.


On 19/04/2020 21:30, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>         Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
>         Authors         : Nat Sakimura
>                           John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-21.txt
> 	Pages           : 31
> 	Date            : 2020-04-19
> Abstract:
>    The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>    query parameter serialization, which means that Authorization Request
>    parameters are encoded in the URI of the request and sent through
>    user agents such as web browsers.  While it is easy to implement, it
>    means that (a) the communication through the user agents are not
>    integrity protected and thus the parameters can be tainted, and (b)
>    the source of the communication is not authenticated.  Because of
>    these weaknesses, several attacks to the protocol have now been put
>    forward.
>    This document introduces the ability to send request parameters in a
>    JSON Web Token (JWT) instead, which allows the request to be signed
>    with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>    (JWE) so that the integrity, source authentication and
>    confidentiality property of the Authorization Request is attained.
>    The request can be sent by value or by reference.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: