Code change:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: [x] "Validate the signature" <- again, cite how to do this. [x] "the typ of the Key Binding JWT" <- is that in the header or payload? (cite 5.3. Key Binding JWT and possibly URL) [x] "within an acceptable window." <- should be an input parameter [x] "validating nonce and aud claims" <- The instructions for doing this should be an input parameter to this algorithm. [x] "Check that the Key Binding JWT is valid in all other respects" should call a particular algorithm from the other specs that it cites.[x] Many of these should be normative. For example, base64url is used all over the normative parts of this specification, and it comes from [RFC7515] in this section.
Thanks for the review Jeffrey! I'm acknowledging it with this comment but also noting that there's a lot here so response/action will take some time.
1c1f165ab821dea5350f62225f103bdceff31532 one was an oversight and one was a tooling issue and oversight. I think that covers them tho.
Those other specs don't have algorithms that can be called nor do they have suitable sections to reference directly.
Some contributors want to leave open the option of a more computationally expensive hash with smaller salt values.
Yes and I've tried to remove any ambiguity there by just not using the word "value" with d015a3de2ae50623b4a294590fb2d0249e7d33b5
Per , "JWTs are always represented using the JWS Compact Serialization" the compact serialization is already specified.
That is for the claim in Key Binding JWT so isn't relevant elsewhere.
& Yeah, with 2a0e270f2e1dbfa9664bb5ce4989a2f6a1765217 I basically applied your suggestion to both places.
Yup 7d68d4ed9b91e49a0aa00254475bf7c116669dd6
Yes but I believe it's sufficiently clear in the context of the draft.
This draft is not structured such that it has input parameters to algorithms so suggestions to make something an input parameter to an algorithm are not actionable or practical.