Subject: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 03:28:34 -0700

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work on this document. I only have minor comments, the most
interesting is probably 4. about if additional failure behavior should be
defined at the AS.

Francesca

1. -----

   A Request Object (Section 2.1) has the "mime-type" "application/

FP: Please use "media type" instead of "mime-type" and reference
https://tools.ietf.org/html/rfc6838

2. -----

   The following is an example of the Claims in a Request Object before
   base64url encoding and signing.  Note that it includes the extension

FP: This example is the first time "base64url" appears in the document. I think
it would make sense to mention that base64url is used when JWT is introduced,
for example in the first paragraph of section 4.

3. -----

   If decryption fails, the Authorization Server MUST return an
   "invalid_request_object" error.

...

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error.

...

   If the validation fails, then the Authorization Server MUST return an
   error as specified in OAuth 2.0 [RFC6749].

FP: very minor, but I suggests you add "to the client, in response to the
request defined in 5.2.2. of this specification". The reason is that the doc
specifies that the AS might be having other exchanges (to fetch the Request
Object) at the same time, and it can't hurt to be precise. Also regarding the
reference to RFC 6749 - can you add a specific section to reference?

4. -----

   specified in the "alg" Header Parameter.  If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be

...

   same parameter is provided in the query parameter.  The Client ID
   values in the "client_id" request parameter and in the Request Object
   "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does the AS
return an error to the client then? Same comment "... MUST be identical" - is
any error returned if it's not?

5. -----

   location, (b) check the content type of the response is "application/

FP: For consistency, please change "content type" to "media type".