[jose] Re: Do you need the JWP JSON Serialization?

[David Waite <[e-mail]>]

> On Aug 8, 2024, at 12:18 PM, Orie Steele <[e-mail]> wrote:
> 
> 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".

A tilde has two meanings in JWP, neither of which universally map to unprotected headers. Since algorithms have a certain amount of flexibility within their layering, I suppose they could potentially map into something like countersignatures in individual cases.

> 
> 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.

In SD-JWT, my interpretation is that the use of a custom compact encoding is far more powerful than unprotected headers as it actually provides requirements and guidance on use due to imposing a specific, non-compatible structure. There are edge cases for SD-JWT where the preprocessor MUST be used for claims to otherwise be conformant to their own requirements (such as redacted members of an array). 

There is also no appropriate “must understand” at the JOSE level for things like the key binding JWT or the disclosures. From a layering perspective, it is unfortunate from a layering perspective that we are pushing requirements to understand certain unprotected headers and payload preprocessing requirements onto the payload content type - although that is also somewhat the original point of SD-JWT.

I would argue that unprotected headers in JOSE have insufficient guidance around correct usage by applications. Specifically, while the JOSE header is the union or protected and unprotected parameters, there is no guidance on how applications should deal with verification having non-integrity-protected header values.

The security consideration around algorithm protection is the only place we get close to mentioning that an implementation may need to specifically check that some header parameters are within the protected header, and otherwise leaves this to an application-level choice.

There is also this unfortunate text in RFC 7515, Section 4:

JOSE Header

For a JWS, the members of the JSON object(s) representing the JOSE
Header describe the digital signature or MAC applied to the JWS
Protected Header and the JWS Payload and optionally additional
properties of the JWS.  The Header Parameter names within the JOSE
Header MUST be unique; JWS parsers MUST either reject JWSs with
duplicate Header Parameter names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in
Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].

Talking about duplicate parameter names at the JSON parser level in this context misleads implementers to think that this is talking about duplicates within a protected header or a unprotected header, not duplicates across the two while performing a union to get the JOSE Header. Conversely, applying the “lexically last duplicate” parser call-out might even imply that the unprotected header parameters would acceptably take precedence over the protected header parameters during this union.

(FWIW, COSE defines this collision as a SHOULD, but does indicate a required preference from the protected bucket. It also indicates alg MUST be authenticated, except in the non-enumerated cases where it can't be. Some headers have call outs that that they are appropriate to be in an unprotected header or that they should be in a protected header, but I would not call it a consistent requirement for header definition)

<snip>

> 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.

Since JWP involves distinct headers from multiple parties (and interpretation of these headers potentially by multiple parties), and also has a stronger need for privacy considerations, I would expect far more definition would be needed for unprotected headers in JWP than was present in JWS/JWE or COSE.

Proofs are also iMHO more likely to be involved in a protocol rather than to protect documents/data at rest, due to being generated in response to a particular request. (The expired https://datatracker.ietf.org/doc/html/draft-waite-jws-multi-payload-00 was partially meant to bridge that gap (to allow for applications defining their data as multiple payloads to have a compatible, non-proof mechanism for representation, but I didn’t perceive any traction around that document and have so-far abandoned the effort.)

If a JWP is being transferred in the context of a protocol, there are plenty of other mechanisms to convey additional unprotected data, without the need to define processing rules or privacy considerations for these within JWP.

For those reasons, I’ve been more interested in entertaining specific functionality carve-outs when proposed as part of JWP, rather than a catch-all like unprotected headers.

-DW