The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
draft-ietf-oauth-jwsreq-34

EDIT (09-04-2021)

Thank you for addressing all my comments in v-34.

Francesca

=============== Original ballot - 07-04-2021

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

Ah, jwsreq.  We meet again.  Fortunately, looking only at the diff from my last ballot comments to this one, I only have a couple of minor things this time:

Sections 9.2 and 9.3 each say they are registering "values", but each registers only one.

"+1" to Francesca's points #1 and #5.

Thanks for changing the media type name to use hyphens instead of dots.  That avoided a big mess.

Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly the diff).

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Is it normal that the abstract has a) and b) while the introduction has a), b), and c) ?

-- Section 5.2 --
I see that "Many phones in the market as of this writing" is still in the text... Does this assertion still hold in 2021 ? Is it backed by some references ?

Thank you for the new security considerations text in Sections 10.7 and
10.8 since I last reviewed; it does a great job capturing my comments
(and the current deployed reality).

Thanks also to Watson Ladd for the latest secdir review and the authors
for their responses to it.

Section 6.2

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  The signature MUST be
   validated using a key associated with the client and the algorithm
   specified in the "alg" Header Parameter.  [...]

The last version I reviewed had some language tying the algorithm used
for verification back to a registration (and I commented that perhaps a
registration might not always exist).  This language seems to set the
recipient up to blindly use the "alg" header parameter, even if it's
"none", and we should probably have some hedging language here (I see we
do have language elsewhere that bans "none" specifically)...

                                             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
   performed, as specified in Sections 3.1 and 3.2 of [RFC8725].

... and maybe that would just take the form of swapping the order of
these two sentences, now that I keep reading.

Section 10.2

Do any of the procedures listed for steps (c) and/or (d) need to be
performed in step (e) as well?  (In particular, the requirements on the
returned URI seem like they would still apply, and possibly the need for
client authentication.

Section 10.3

Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my
previous review suggested that there might be value in future work that
specifies the linkage across these endpoints to try to address the
cross-phase attacks discussed in [FETT].  However, the paragraph that I
had commented on (that mentions "an extension specification") has since
been removed, and I failed to track down why just from a quick
mailarchive search.  There may well have been a good reason for removing
it (and the reference to [FETT]), so please help refresh my memory if
that's the case.

Section 10.4

   The introduction of "request_uri" introduces several attack
   possibilities.  Consult the security considerations in Section 7 of
   RFC3986 [RFC3986] for more information regarding risks associated
   with URIs.

My previous comments had mentioned that because of time skew the
dereferenced request URI might actually have the contents of a different
request than the one intended, and Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/
pointed out that OIDC actually does use a nonce that would prevent such
an occurrence.  Hopefully Nat did get a chance to think about whether
there was anything else that we should mention in this document, on this
topic.  ("There isn't anything else to mention here" is a fine answer; I
just wanted to close the loop on that thread, since I didn't find one in
the mail archive.)

Section 11.1

nit: s/TFP/trusted third-party service/ (multiple instances), since we
stopped using "Trust Framework Provider" in the main body.

Sction 14.1

Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 --
thank you for referencing it as BCP 195!  I expect the RFC Editor will
catch the new reference if you don't want to figure out how to notate it
properly.

Section 5.2, paragraph 5, comment:
>    The entire Request URI MUST NOT exceed 512 ASCII characters.  There
>    are three reasons for this restriction.
>
>    1.  Many phones in the market as of this writing still do not accept
>        large payloads.  The restriction is typically either 512 or 1024
>        ASCII characters.
>
>    2.  On a slow connection such as 2G mobile connection, a large URL
>        would cause the slow response and therefore the use of such is
>        not advisable from the user experience point of view.

What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to
transmit; it's not clear that larger payloads would therefore be so much worse,
given that the 2G latencies are probably the overriding issue here. Would a
SHOULD NOT suffice?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 4, paragraph 10, nit:
-    Signing it with the "RS256" algorithm results in this Request Object
+    Signing it with the "RS256" algorithm [RFC7518] results in this Request Object
+                                          ++++++++++

After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just an editorial fix.

If the server advertises that a signed object is required, then it cannot communicate with a client that does not support the extension. But if the object_required metadata is missing, then what is the metadata that tells the client to use a signed object if it can?

IIUC the answer is that the server metadata includes the request_object_signing_alg_values_supported and/or request_object_encryption_alg_values_supported parameter in the metadata. It might be helpful to spell that out here.

Is this correct?