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

From: [email-masked]
Date: Sun, 19 Apr 2020 11:30:22 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 20 Apr 2020 09:12:14 +0300

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
wording:

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.

Vladimir

---

From: Brian Campbell <[email-masked]>
Date: Tue, 21 Apr 2020 07:12:37 -0600

I'd agree that Vladimir's proposed wording is more meaningful/helpful.

On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> cases, even for those when it can be readily extracted from the JWT, makes
> the job of implementers even easier.
>
>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21
>
> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 26 Apr 2020 17:16:35 +0200

Hi Nat & John,

I tried to find out how signing & encryption algorithms are determined in the JAR context. 

I just found this note in the history for -07: "Stopped talking about request_object_signing_alg”

I assume you assume this is done via client registration parameters registered in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata? Why doesn’t JAR state so?

What is about algorithms supported by the AS? The respective parameters, such as request_object_signing_alg_values_supported are not registered yet in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata.

best regards,
Torsten. 

> On 19. Apr 2020, at 20:30, [email-masked] wrote:
> 
>