[OAUTH-WG] AD Review of draft-ietf-oauth-par-07

[Roman Danyliw <[e-mail]>]

Hi!

I performed my AD review of draft-ietf-oauth-par-07.  Thanks for the effort to produce this document.  See my feedback below:

** Section 1.1.  Per the first POST example, please provide a bit more text to explain the presence of the Authorization header.

** Section 2.1.  Per step #1, "Authenticate the client in the same way as at the token endpoint." Would it be appropriate to cite Section 2.3.1 of RFC6749 as the reference for "the same way"?

** Section 2.1. Typo.  s/the the/the/

** Section 2.2.  "The format of the "request_uri" value is at the discretion of the authorization server ...", it would be helpful to remind implementers (via reference) that the constraints of Section 10.10 of RFC6749 apply.

   The authorization server MUST prevent attackers from guessing access
   tokens, authorization codes, refresh tokens, resource owner
   passwords, and client credentials.

   The probability of an attacker guessing generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

** Section 2.2.  "The string representation of a UUID as a URN per [RFC4122] is also an option for authorization servers to construct "request_uri" values" suggests that a UUID could be used as the "cryptographically strong pseudorandom algorithm such that it is computationally infeasible to predict or guess a valid value" for the random part of the request_uri.  However, a few bits of the 128-bit UUID are in fact not random.  Hence, this UUID construct would seem to violate the guidance of Section 10.10 of RFC6749 noted above.  Likewise, the Section 10.2 of draft-ietf-oauth-jwsreq-34 referenced in Security Considerations also suggest 128-bits.

** Section 2.4.  This section relaxes exact matching of the redirect_uri specified in the current text of the security BCP and OAuth 2.1.  Not relevant to this document, but would it make sense to acknowledge this relaxation in the BCP or caveat language about strict requirements in the v2.1 draft?

** Section 6.  Typo. s/reqired/required/

** Section 7.5.  Per "Clients SHOULD make use of PKCE, a unique "state" parameter, or the OIDC "nonce" parameter" are good advice.  Can the text provide references to each of these.

** Section 8.  Wouldn't some of the privacy considerations of draft-ietf-oauth-jwsreq-34/Section 11 apply?

Thanks,
Roman