I'm not sure that clarifies things much, Mike, at least for me. Maybe you could help fill in the analogy for me:
JWE represents confidentiality protection JWS represents authenticity/integrity protection JWP represents ...? In other words, it seems like JWE and JWS were straightforward implementations of well-understood cryptographic functions. What is the single, clear cryptographic function that JWP would provide? On Thu, Jul 28, 2022 at 2:43 PM Mike Jones <Michael.Jones= [email protected]> wrote: > > But from these discussions it seems that JWP is really its own separate > thing. > > > > They are separate in the same way that JWS and JWE are separate. JWP has > a different syntax than JWS or JWE but reuses many of the design decisions > and components, when applicable – just like JWE reused many of the design > decisions and components from JWS. > > > > Also, per my presentation at the BoF > <https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-the-need-standards-for-selective-disclosure-and-zero-knowledge-proofs-00>, > the JOSE working group members have experience creating simple and > widely-adopted JSON-based representations for cryptographic objects. The > simplest way to ensure that that expertise is brought to bear is to, in > fact, do the work in the JOSE working group. > > > > -- Mike > > > > *From:* jose <[email protected]> *On Behalf Of * Neil Madden > *Sent:* Thursday, July 28, 2022 1:13 PM > *To:* Jeremie Miller <[email protected]> > *Cc:* Tobias Looker <[email protected]>; Torsten Lodderstedt < > [email protected]>; [email protected] > *Subject:* Re: [jose] JWP > > > > > > On 28 Jul 2022, at 16:47, Jeremie Miller <[email protected]> wrote: > > > > No, to prevent this the issuer simply puts these sorts of claims in the > header, which is not subject to selective disclosure, e.g the prover cannot > create a valid proof/presentation without disclosing the original > un-modified header. > > That is a very non-standard use of the header. AFAICT such usage is not > compatible with RFC 7800, and I would guess that it may well lead to > security issues as implementations won’t be looking for these claims in the > header but rather in the claims set. > > > > That's one of the reasons we're proposing JWP as another specification, it > is not compatible with existing JWTs+PoP. > > > > Also, a current security assumption baked into the JWP draft is that all > presentations are not replayable. While this can be accomplished with a > proof-of-possession it is not the only mechanism an algorithm could use, > BBS for example supports this without requiring a traditional PoP. > > > > > > So I guess then why do this in the JOSE working group if the work has > little in common with existing JOSE specs and semantics? Different > algorithms, different formats, different processing rules. It’s not clear > if JWP could even reuse the IANA JWT Claims registry if you’re saying that > it’s not compatible with some of them (eg cnf). > > > > The proposed new charter says: > > > > “The current JOSE and JWT specifications are not sufficiently general to > enable use of these newer techniques. The reconstituted JSON Object Signing > and Encryption (JOSE) working group will build on what came before but also > rectify these shortcomings.” > > > > But from these discussions it seems that JWP is really its own separate > thing. (Indeed the JOSE specs are already criticised for trying to be too > general). > > > > — Neil > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
