Code change:
Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, <del> Pieter Kasselman, Ryosuke Abe, 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> Pieter Kasselman, Richard Barnes, Ryosuke Abe, 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: Remove initial underscore on for I do think this change is appropriate but think we should publish a -07 soon if we proceed with it.
It makes sense for to start with an underscore, since it is being inserted into a JSON object supplied by the caller and it needs to be something unlikely to conflict with an existing claim. The field appears in the key binding JWT, a format being defined by this document. So it can safely live without the underscore.
That's a fair point, I think.
I think the same argument also applies to . It's just a normal JWT claim, so it can be deconflicted using the usual registry process.
Really they are all just JWT claims and will be registered. The leading underscore isn't magical and doesn't exempt from registration. But it is a nicety to help avoid conflict, which is particularly relevant with where/how and are used. They both are in the issuer signed JWT where there is some potential for name conflicts with application supplied data (JWT's whole registered, public and private claims guidance is supposed to help here too but conflicts are still possible). For general clarity and consistency, I agree (I think anyway) with removing the initial underscore on . But is more similar to in usage/context and those two should keep their leading underscore.
To me the difference between and seems to be that is at the top level of the JWT claims, where we're used to dealing with . But can be down in the guts of the claims, which the JWT signer might have less control over. So I would go for , but and .
Registered claims (I'm a so-called DE on there so I have some familiarity) don't fully address conflicting names even at the top level with the possibility of the use of private claim names. More could be said about that registry and what it does and doesn't provide in practice but that'd be a digression... Anyway, that and show up in the content of issuer-signed JWT is my point of vew for keeping the underscore on both. Also for keeping those two similar to each other. Lastly note that and have been in the draft for many revisions (back to -02 I think) whereas was just introduced in -06. Changing at this point likely wouldn't impact implementations much but changing would.
I'd prefer to not see ANY public claim names that start with . It starts a convention which I would prefer not to see repeated.