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

[Orie Steele <[e-mail]>]

That only applies to "SD-JWT+KB"

Because: ... "kb_jwt MUST be present when using the JWS JSON Serialization,
and the digest in the sd_hash claim MUST be taken over the SD-JWT as
described in Section 5.3.1."...

If we are talking about just the SD-JWT without any key binding... the
order of disclosures could change / does not matter, and there is only the
integrity protection afforded by checking that they are all present per:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-8.2

Before the holder secures the disclosures with kbt, the holder controls
their order, and the eventual sd_hash.

Unless I am mistaken, there is no ordering requirement for the SD-JWT
without key binding, so the disclosures are mutable, until the holder makes
them immutable by applying key binding:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-5.3.1

As I noted before, when you don't build in an ability to bucket related
objects, they get grouped together and through string concatenation.

In SD-JWT: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure
2>~...~<Disclosure N>~ (order of disclosures can change).
In SD-JWT+KB: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure
2>~...~<Disclosure N>~<KB-JWT> (order cannot change)

In JSON Serializations, there can be other unprotected header parameters,
which is why the draft has this text:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.1-4

In Compact Serialization, it is not possible to include any "other
unprotected headers"... this is the point that I am trying to make.

As Brian noted, JWE has similar behavior with single / multiple
recipients... because only JSON serialization supports multiple recipients
and unprotected headers.

Before SD-JWT, a JWT was only compact... that's still true after SD-JWT
since SD-JWT is not a JWT, it's a JWT that can have a ~ in it, and possibly
another JWT at the end.

After SD-JWT, you can have a "SD-JWT that is JSON Serialized"... even
though you can't really have a "JWT that is JSON Serialized"... technically
what JADES produces is just JWS in JSON Serialization... it's not a "token".

All of this is more confusing than having a text and object representation
that support the same set of features... which is what COSE has.

SD-JWT is an improvement over JWT in this regard.

OS


On Thu, Aug 8, 2024 at 2:20 PM Neil Madden <[e-mail]> wrote:

> Maybe I’m missing something, but all of the disclosures are covered by the
> SD-JWT signature and so (a) are protected, and are (b) immutable.
>
> — Neil
>
> On 8 Aug 2024, at 19:18, 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".
>
> 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-2
>
> Sure 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
>
>
>
>
>
> 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/>
> _______________________________________________
> jose mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>