Original text:
10.11. <del> Section 3.11 of RFC8725 describes the use of explicit typing to prevent confusion attacks in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the </del>  header parameter when the SD-JWT is issued, and for Verifiers to check this value. <del> When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.  The definition of </del>  in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter.  11. The privacy principles of ISO.29100 should be adhered to.

Reviewer comments:
From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Revised text:
10.11.  <ins> RFC8725 describes the use of explicit typing as one mechanism to prevent confusion attacks (described in RFC8725) in which one kind of JWT is mistaken for another.  SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it is RECOMMENDED that application profiles of SD-JWT specify an explicit type by including the </ins> header parameter when the SD-JWT is issued, and for Verifiers to check this value.  <ins> When explicit typing using the header is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD- JWT.  The definition of </ins> in Section 4.1.9 of RFC7515 recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the header parameter. <ins> Use of the content type header parameter to indicate the content type of the SD- JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. </ins> 11. The privacy principles of ISO.29100 should be adhered to.