Refine claims and header parameters in JWP

[dwaite]

For issued messages, there is motivation to have as little in the protected header as possible, as this data is exposed to all participants and even small changes like formatting could serve to leak bits of information that could lead to additional fingerprinting of presentations.

Through ZKP it is also possible to formulate presentation proofs that a message came from a valid issuer, and not a particular key from a particular issuer. With such a setup, even these normally important header parameters might be omitted.

For presentation, we have promoted a number of header parameters from claims, however this is really a function of the header being an application block, e.g. information from the holder to the verifier as part of the protocol that presentation is happening under. This is something which also has happened with other JOSE/COSE protocols, such as "CBOR Web Token (CWT) Claims in COSE Headers" (RFC 9597).

Finally, there is motivation to try to evaluate JWP with a common data model, e.g. that CBOR and JSON form their headers from a common data model, and that it is possible (although not required) for JSON Proof Tokens (and their CBOR equivalent) to do the same. This means that certain values like nonces and key identifiers which differ somewhat arbitrarily between the two should have a common data model (with nonce being a JWT/CWT claim, and kid being a JWS/COSE Header Parameter which we may want to represent as a payload).

The proposal I put forth here is:

1. Within JWP, Header Parameters and Claims are based on a common named value root concept called a Parameter.
2. Parameters may be present either in the header (where they are in a JSON Object or CBOR Map) or as individual payloads with names mapped to offsets
3. We define a way for claims from other registries (JWT and CWT) to be used in a manner where they do not have name conflicts, such as a name prefix and CBOR labels of non-overlapping numeric ranges between CWT and JWP. There is specifically not a way defined for headers from these registries to be mapped in, preferring they be respecified as JWP headers.
4. We define a suitable set of Parameters in JWP specifically for the purpose of providing a baseline common data model, e.g. binary string in CBOR represented as base64uri in JSON, CBOR resolved to string name via table lookup.

[selfissued]

I'm skeptical of trying to unify things that have heretofore been different, particularly if it causes us to resort to unnatural acts like defining prefixes to use JWT claims, etc. That said, I'm open to be convinced of the advantages of doing so if it can be done in a clean and natural way.