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

[Brian Campbell <[e-mail]>]

On Thu, 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".
>

That's fair :) But I would have vehemently argued against that different
design.



> In JOSE, ~ is just used as a placeholder for "missing unprotected header".
>

This is entirely incorrect.



> 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 basically a summary of some of how SD-JWT works. Except it's
missing the whole salted hash to disclosure check that ensures the
integrity (as issued by the issuer) of the selectively disclosable claims.
Which is arguably the core and most important feature of SD-JWT.

This section tries to describe what is integrity protected and by whom in
what situations:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.10
that might help or further derail this conversation.



>
> That is very similar to the kind of unprotected header processing that
> COSE supports, see:
>
> https://www.rfc-editor.org/rfc/rfc9338.html#section-2
>

There are some similarities but I'd be careful not to overstate them.



> Sure maybe it's less obvious that jwt (cnf) -> disclosures -> hash -> kbt
> signed by cnf is a kind of counter signature.
>

Sure, I guess it is a kind of counter signature. Kinda. But really it's a
purpose built proof-of-possession mechanism that also happens to be a
signature that includes a hash based integrity check over the set of
selected disclosures. It's there because some folks thought it was needed
(I'm still not totally convinced but rough consensus and everything so it's
there and it doesn't hurt anything other than added complexity and more
potential interoperability problems).



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

Speaking strictly as an individual - those new unprotected headers in the
JWS JSON serialization for SD-JWT are an extremely awkward design from a
data model perspective.  There are "reasons" it ended up that way but that
doesn't make the design a good one or something to point to as a pattern to
follow.

The entire SD-JWT JWS JSON serialization is arguably a mistake. One which
was necessitated by a series of mistakes that came before it; starting with
the JOSE JSON serialization, which I'll suggest never should have existed.



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

Amusingly (to me anyway), I gave Dr. Daniel Fett a hard time (in a
hopefully friendly way) when he wrote the very sentence you quoted. I
thought it was kind of silly to point out the obvious like that. But maybe
the need to write something like that underscores some of the potential
pitfalls inherent in a feature like unprotected headers.



>
> Isn't JWP meant to replace SD-JWT in some cases that require stronger
> unlinkability?
>

I do think there are people who perceive it that way.



>
> IIRC SD-JWT and OAUTH had good reasons to define a JSON Serialization,
>

OAuth in general has never had need for the JOSE JSON Serializations. And,
as alluded to above, the reasons behind the SD-JWT JSON Serialization are
not widely considered good.



> and if it's used, those users should be able to switch to JWP or CWP in
> the future.
>

Any such switch is going to require some changes in some places. Probably a
lot of them. Trying to design for and/or optimize for a hypothetical future
switch does not seem to me like it should be high on the priority list of
considerations.



> OS
>

BC


>
>
>
>
>
> On Thu, Aug 8, 2024 at 12:33 PM Brian Campbell <[e-mail]>
> wrote:
>
>>
>>
>> On Thu, Aug 8, 2024 at 11:27 AM Orie Steele <[e-mail]>
>> wrote:
>>  <snip>
>>
>>>
>>> If JWTs had unprotected headers, I suspect SD-JWT would have used them
>>> for the mutable part (disclosures).
>>>
>>
>> That suspicion is entirely incorrect.
>>
>> <snip>
>>
>>
>> *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.*
>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>

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