Review by Aaron Parecki

[yaronf]

• One application area in which JWTs are commonly used is representing digital identity information, such as OpenID Connect ID Tokens [OpenID.Core] and OAuth 2.0 [RFC6749] access tokens and refresh tokens

  Change to "representing authorization or identity information, such as
  OAuth 2.0 access tokens [RFC9068] and OpenID Connect ID Tokens
  [OpenID.Core]"

  It is not common practice to use JWTs for refresh tokens, since
  refresh tokens are only consumed by the issuer, whereas access tokens
  are consumed by the resource server which is a separate role from the
  authorization server that issues them. Also updated the reference to
  the JWT access token spec.

• if a JWT is cryptographically protected end-to-end by a transport layer, such as TLS using cryptographically current algorithms, there may be no need to apply another layer of cryptographic protections to the JWT. In such cases, the use of the "none" algorithm can be perfectly acceptable.

  This makes it sound like it's acceptable to send alg none JWTs as
  access tokens over TLS, which is obviously not true. I would suggest
  removing all references to alg none being acceptable. If there is an
  actual concrete use case for alg none JWTs, list it out explicitly,
  preferably to a reference of a spec/profile that uses it.

• Section 3.3 mentions the term "Nested JWT" capitalized, but this is
  the first occurrence of the term in the document. Add a reference to
  where Nested JWT is defined, or change to lowercase if the intent is
  to mention the general concept of nested JWTs.

• The means of determining the keys owned by an issuer is application-specific. As one example, OpenID Connect [OpenID.Core] issuer values are "https" URLs that reference a JSON metadata document that contains a "jwks_uri" value that is an "https" URL from which the issuer's keys are retrieved as a JWK Set [RFC7517]. This same mechanism is used by [RFC8414].

• Swap the mentions of RFC8414 and OpenID Connect: "As one example,
  Authorization Server Metadata [RFC8414] issuer values are .... The
  same mechanism is used by OpenID Connect [OpenID.Core]."

• Similarly, when the JWT contains a "sub" (subject) claim, the application MUST validate that the subject value corresponds to a valid subject and/or issuer-subject pair at the application

  This would benefit from an explicit reference to Section 4.15 of
  RFC9700 https://datatracker.ietf.org/doc/html/rfc9700#section-4.15
  which talks about the possibility of client_id vs user identifier
  confusion.

• Section 3.10: change "whitelist" to "allowlist". There is already a
  prior use of "allowlist" in the doc, so I assume this was
  unintentional.

• Also in section 3.10, mention that the AS should check what the
  hostname resolves to and avoid making a request if it resolves to a
  loopback or internal IP address. (e.g. someone uses the value
  "attacker.example.com/etc/passwd" as the jwks_uri, but adds a DNS
  entry for "attacker.example.com" to resolve to "127.0.0.1" or other
  internal IP address ranges.

• Section 3.11: "Sometimes, one kind of JWT can be confused for another."

  This is kind of vague and would benefit from more explicit examples.

CC: @aaronpk