Re: [jose] JWP

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=
40microsoft.com@dmarc.ietf.org> 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 <jose-bounces@ietf.org> *On Behalf Of * Neil Madden
> *Sent:* Thursday, July 28, 2022 1:13 PM
> *To:* Jeremie Miller <jeremie.miller@gmail.com>
> *Cc:* Tobias Looker <tplooker@gmail.com>; Torsten Lodderstedt <
> torsten@lodderstedt.net>; jose@ietf.org
> *Subject:* Re: [jose] JWP
>
>
>
>
>
> On 28 Jul 2022, at 16:47, Jeremie Miller <jeremie.miller@gmail.com> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>