That's fair : )
Let's replace "suspicion" with "I would have argued for a different design".
In JOSE, ~ is just used as a placeholder for "missing unprotected header".
You still need to validate that the correct mutable data was included, and that no "unexpected mutable data" was included.
That's a "verifier policy over mutable data".
In the context of SD-JWT that means checking disclosures, matching their hash to the kbt and making sure the kbt is signed by the cnf.
That is very similar to the kind of unprotected header processing that COSE supports, see:
https://www.rfc-editor.org/rfc/rfc9338.html#section-2Sure maybe it's less obvious that jwt (cnf) -> disclosures -> hash -> kbt signed by cnf is a kind of counter signature.
But it is a second signature, over a specific set of disclosures that is grouped together with the first signature, which are verified together.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.1"""
Unprotected headers other than disclosures are not covered by the digest, and therefore, as usual, are not protected against tampering.
"""
This is similar to how values in unprotected headers in COSE are not protected, unless there is some "verification process" such as checking a counter signature, or merkle tree inclusion proof.
Isn't JWP meant to replace SD-JWT in some cases that require stronger unlinkability?
IIRC SD-JWT and OAUTH had good reasons to define a JSON Serialization, and if it's used, those users should be able to switch to JWP or CWP in the future.
OS
