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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On Thu, Aug 8, 2024 at 11:27 AM Orie Steele <[email protected]> >> 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 -- [email protected] > To unsubscribe send an email to [email protected] > > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
