Code change:
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.
In OpenID Connect, we decided that our "meta-claims" would start with underscore to visually distinguish them from normal claims. For instance, see the claims and in the registry at URL I support SD-JWT continuing to follow this convention and so would prefer that the leading underscore be kept for its meta-claims.
NAME What is the difference between "normal claims" and "meta-claims" here? And why did OpenID Connect go that way?
"Meta-claims" are claims about the structure of where actual claim values can be found - claim values that are not simply top-level members in the JWT Claims Set. They're road-signs saying where to go to get them - not the destinations themselves.
Thanks, that distinction makes sense. Applying that to SD-JWT, it seems directly applicable to , and sort of fits as well, since it tells you how to read the road-signs (to continue NAME metaphor). I'm OK with these keeping ``. But is not a road-sign, it's the main event. If you ignore or , you miss out on some claims, but nothing fundamental breaks. If you ignore , you're not enforcing the key security properties of the system. So I think the original issue here is still valid.
PR URL would remove the leading underscore on (and only there). Which is the original issue here.

Related discussion:
text: 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.