JWK Thumbprint URI
draft-ietf-oauth-jwk-thumbprint-uri-03

Thank you for the work on this document.

Many thanks to Gonzalo Salgueiro for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/l3PXPUp3p3ID0cMF27g7uNQSGxQ/.

# GEN AD review of draft-ietf-oauth-jwk-thumbprint-uri-02

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/OUPrqEJ7DNFPcaL9Goc7-7rZy_4).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
   binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
   `unacceptable`, `inapplicable`, `revoked`, `rescinded`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

One suggestion: This document cites BCP 14, and then barely uses it (there's just one "MUST", and nothing else).  In my view, you could replace "MUST be" with "are" and then drop all the BCP 14 boilerplate, with the same effect.

Hi,

I just wanted to confirm that the names of "Hash Name String" in the IANA registry are always such that they can be directly used in URLs without encoding.  RFC 6920, section 9.4, didn't seem to specify any restriction, but text if the rest of that RFC (that I'm not really familiar with) seems to suggest/indicate that they use a restricted character set and hence are safe to directly embed.

Thanks,
Rob

Thank you to the authors and WG for this document -- I was somewhat apprehensive about reviewing it, because I'm clearly not an expert on OAUTH / JWK... however, I was pleasantly surprised to discover just how readable (and short :-)) it is, and that even I could understand it.

Also, much thanks to Scott Bradner for his OpsDir review (https://datatracker.ietf.org/doc/review-ietf-oauth-jwk-thumbprint-uri-01-opsdir-lc-bradner-2022-05-08/) and suggestion on how to address it.