JSON Web Proofs (JWP) Virtual Interim BOF

Wednesday, 12 October 2022, 1700 UTC
https://datatracker.ietf.org/meeting/interim-2022-jwp-01/session/jwp

1. Administrative and Agenda Bash (Chairs - 10 min)

Reminders: this is a WG-forming BOF. There was a short version in
Philadelphia this is a continuation. Focus is whether or not to have a
formal WG or how we want to tackle the issue.

2. Why are we proposing to do this work? (Jeremie / Mike, 15 minutes)

• Jeremie Miller (JM)
  • I realize after our discussion, we chose a feature first
    description but we lost the bigger message in the wake of the
    feature discussion
  • The whole category of capabilities is the focus here. JOSE is
    the history, a key thing is that it is JSON/web friendly, crypto
    agility, vetted algorithms
  • Today the large category of ZKP (zero knowledge proofs) is not
    represented. Most ZKP proofs have a transform or a 'finalize'.
    There can be a state where there is cryptographic agreement
    which then can be modified. To do that today there would be 2
    separate pieces that would have to be externally joined and that
    would be difficult
  • Also today there is a need for the ability to operate on a set
    (ie multiple messages)
  • Representing concepts based on a list or also on the items of a
    list is not feasible with the current stack
  • JWS, JWE have a very well defined interface for what you put in
    and what you get back from the algorithm. There are a lot more
    inputs with ZKP. ZKP has concepts like blinded values that might
    have to be unblinded, etc - no way to constrain that into
    conventional assertion styles

What is a ZKP:

• Interest is radically higher now and ZKP algs require far more
  compute. So need is increasing but compute power has also gotten
  good enough to make ZKP viable

• Very high level:

  • Many families of ZKP - multi-computation, rings and threshold
    signatures, etc. (refer to the slides, there are many examples)
  • Many capabilities are unlocked - predicate proofs and verifiable
    computation is important, including "arranging" proofs, which
    give tools to solve very complicated problems with cryptographic
    integrity

  • Today everyone designs their own custom containers. This limits
    agility

    • You can see this in the blockchain space. Anoncreds eg is a
      custom solution for anonymous credentials

  • We can step up and create a multi-use solution without replacing
    whole protocol infrastructure

• Examples:

  • BBS is a well known/mature example
  • CL signatures are wellknown and deployed at large scale
  • PS Signatures/Mercurial provide malleability
  • ZK Snarks are a "bag of tools" - can be combined into many
    solutions but there is no way to grab one and use it
  • Privacy Pass is widely deployed
  • Schnoor, Algebraic MACs also have to be deployed as one-offs.

• Richard Barnes asked a critical question - what is the single, clear
  cryptographic function that JWP would provide
  * This is critical. JWP is not only about selective disclosure -
  the key contribution is knowledge protection, which isn't available
  yet with JWS and JWE

  • The demand on the privacy/cryptography/identity world is that
    trust will continually be degraded
  • We must build infrastructure where ownership is less binary,
    trust needs to be multi-party. There needs to be a mechanism to
    control trust as data flows.

• There is a lot of interest in support for ZKP from many parties

  • The W3C VC working group added a dependency, and is making an
    explicit liaison request - we are the right place to do this
    work
  • The DIF (decentralized identity foundation) incubated/supported
    this work. They chose to hand to IETF out of respect for the
    IETF's security expertise, the CFRG, and for the IETF's track
    record in cryptographic solutions
  • The CFRG has adopted a draft by Tobias Looker to standardize the
    ZKP cryptographic operations. A potential partnership exists
    where CFRG does heavy lifting for ops and this group can take on
    the container format.
  • Now - want to explicitly invite folks interested in the work to
    describe their interest

3. Discussion of the problem (15 minutes)

Brent Zundel

Our roadmap needs this, we want one that is interoperable, we love that
successful containers have been created in the past and want to see this
happen so Avast cn use.

Orie Steele

Excited about doing this work in the IETF to secure JSON knowledge.
Framing is excellent, one asked how much of this is just very specific
to W3C VC? I am excited to use JWP for securing JSON that isn't W3C VC.
JSON and CBOR need knowledge mechanisms that can capture advancements.
There are new capabilities we need to wrap in envelopes. Many use cases
in W3C can leverage this and build - excited to participate and align,
review and comment. Now is the time, so we don't perpetuate the 'custom
container' anti-pattern.

Mike Prorock

Echoing similar support - I'm with MeasureIO, we deal with food security
related to global disease spread this is important,this work prevents
reinvention of the wheel around problems that need to be standardized by
the right people, those familiar with cryptography.

Tobias Looker

Expressing similar support. BBS was recently adopted and like JWP it
recycles clever design decisions for algorighms such as BBS. Strong
supporter of the work.

Karen O'Donaghue

Questions about the clarity of the problem or whether there is a problem
to solve?

Brian Campbell (BC)

With regard to clarity - the proposed charter text is not consistent
with what is stated here. The charter is still focused on unlinkability
& selective disclosure.

Mike Jones (MJ)

Agreed that the draft charter hasn't been updated. We could do that,
expect that the deliverables will be the same but can update to make the
framing consistent with today's presentation.

John Bradley (JB)

Richard Barnes had some skepticism over the plausiblity of the overall
endeavor, wanted to note that. Another email message expressed
skepticism over SD-JWT but thought that JWP should be chartered (this is
John's interpretation). This WG isn't defining low level algs or high
level use, we are just focused on the container, clarifying in the
charter may help to satisfy most people.

Mike Jones

Thanks John for bringing up list comments, the person in the discussion
(Daisuke) did agree that a WG is needed and also noted that if there is
a WG, it should be JOSE

Poll:

Is there a problem for the IETF to solve? 17 raised, 1 did not raised,
18 participants

Karen O'Donaghue

Consensus is there is a problem to solve.

Carsten Bormann (CB)

Can the not-hand-raiser state why they didn't raise?

Brian Campbell

Was partly struggling with interface, there is a disconnect between the
problem and the proposal to solve it (i.e., the charter)

Carsten Bormann

(in chat) agrees it is not clearly defined

4. How are we proposing to address this problem? (Jeremie - 15 minutes)

• Drafts have been shared out to define possible solution spaces, this
  is just a starting point
• Operations can happen individually but the envelope represents state
  on the set
• Also supports unlinkability, i.e., to perform a transform of one
  cryptographic statement into another cryptographic statement such
  that it is verifiable but not linkable to previous.
• The existing draft incorporates an older BBS definition and already
  demonstrates portability to latest revised BBS, it can plug in new
  algs and non-ZKP algs showing crypto agility
• Focusing on familiar patterns, same type of header, payload
• Reusing parts of JOSE. JWK only needs small extension, looking to
  inherit as much as possible
• These drafts are not at all final - just a potential starting point
• Example JWP still has protected header, has multiple payloads, with
  tilde separating (the only URL-safe character left). Proof contains
  enough info to verify payloads separately and also protect header
• Ability exists to do predicate proofs, not revealing payload but
  including information about the payload.

JB: clarifications: these documents would be submitted for consideration
to a WG should it be created, these are proposals and could be accepted
by the WG. Not saying these documents are accepted, others may submit
very different proposals. In SD-JWT, multiple objects have been "bodged"

together. In contrast, JWP has less gluing together.

5. Discussion of the possible solution (15 minutes)

MJ: reminder, solutions are the job of the WG. The drafts are an
existence proof - evidence that the problem can be solved
MJ: reviewing questions from last BOf

1. Isn't JWS/JWT enough? JOSE can't represent ZKP. More ZKP inputs are
   needed and there is no represenation for inputs, as well transform
   or finalize steps are needed
2. Isn't SD-JWT enough? These comparisons are fair, and SD-JWT has been
   adopted. SD-JWT is explicitly designed to support selective
   disclosure. It is enough for some use cases but doesn't enable rich
   properties that ZKPs do. So SD-JWT is great but doesn't take us all
   the way to solve the problems that ZKPs solve.
3. What about CBOR? The WG could create a CBOR container and that is in
   scope. Plan is to start with JSON based container recognizing that
   CBOR should be easier due to its native binary support. Hopefully
   the same folks will collaborate.

Carsten Borman: you are hitting right points. Another complication is
compact format and tilde, there is no room for another hierarchy,
nightmare scenario is that design leads to an information model that is
impossible to understand. Would rather not design something completely
around limitations of JWT/JOSE, so question is should we do CBOR design
at the same time and avoid the problem.

MJ: agree and hope Carsten will be there to collaborate. Historical
note: There are 2 serializations in JOSE, compact and JSON. Multiple
signatures are part of that 2nd serialization. It is possible that there
will be 2 serializations in this JWP work too. Even in COSE there were
different optimization paths, not pre-judging what the WG will do.

KO: questions about interest, comments on high level solutions,
willingness to participate

JB: does anyone think existing work adequately addresses the problem?
KO: anyone who disagrees?

Roman Danyliw (Area Director): lets agree there is consensus if nobody
is speaking up. Don't need to use the poll tool.

1. Is there agreement that existing IETF work does not address this
   problem?

   • No disagreement

2. Is there enough work here for a working group in the IETF?

   • No disagreement

3. Is there sufficient interest in doing this work?

   • KO it seems from the chat logs that there is sufficient interest

4. Who is willing to participate? (Poll)

   • Raised hand: 13, Not raised: 0, Total Participants: 13 of 21
     people in the chat

5. Who is willing to review? (Poll)

   • raised hand:16, not raised: 0, participating 16 of 21 people in
     the chat

6. Proposed Charter (15 minutes)

KO: We've heard that it doesn't yet reflect the framing that Jeremie and
Mike provided today.

MJ: I can revise the messaging in charter intro. The deliverables
shouldn't change.

RD: Hearing we have to change charter but consensus check: is there
support for the deliverables as described in the charter?

Charter:
https://github.com/json-web-proofs/json-web-proofs/blob/main/charter-ietf-jose-03.md

In chat, CB said he would alter the test vectors a bit that will be for
WG to decide

Consensus call: Would you support chartering a WG around deliverables?

• raised hand: 14, not raised: 0, participants: 14
  Participants: 14 of 20 people

Peter Saint Andre: Question - charter says that there is talk of
creating algs

MJ: We will specify for algs how inputs/outputs are represented but
explicitly disclaim alg work. Will take similar text directly from COSE
charter and fix that text.

KO: confirming changes including test vectors, and statements on making
algs

Shawn Butterfield (SB): is it appropriate to reference SD-JWT?

MJ: there is a reference and intent to coordinate stated directly in the
charter text

SB: (thumbs up)

RD: seems like we have consensus for deliverables, how about rest of
charter (incremental consensus)? We can get consensus on charter as is
then collect feedback on edits and understand magnitude.

KO: anyone opposed to using existing charter as a starting point and
then editing?

• sensing there is no objection to starting with existing charter.
  What specfic edits are needed:
  • MJ willing to align intro text to framing from today's
    presentations
  • MC - main objection is claim that selective disclosure/data
    minimization is a limitation of existing JOSE/JWT stack, esp
    when linking to a doc like SD-JWT that does exactly that later
    on.
  • MC - limitations exist, but selective disclosure isn't one of
    them. Would like to see that re-phrased.
  • JB - rephrasing potentially to say that detached signatures and
    detaching payloads would be needed to do selective disclosure,
    is that accurate? ie not contained entirely in a single JWS. JWT
    can't do SD in a single object whereas JWP could. You can add
    stuff on but interoperability and scalability suffers
  • MC you're right, SD-JWT is adding but the charter frames as
    saying SD is impossible. Looking for a more reasonable
    statement.
  • Gabriel Bauman (in chat) "+1 John. We need to clarify. You can
    compose a SD solution out of JWTs, but JWTs are just components
    of a SD solution"
  • Vittorio Bertocci (VB) no doubt that work must be done for
    interoperable containment. Layering could be better explained,
    ie why do things have to live at the JWT layer. Explain
    (somewhere) why other layers are not desirable. Include reasons
    or hints for advantages (ie one single cryptographic composure).
    Would not be well equipped to explain to a customer based on
    what is here today
  • JB good suggestion (lots of +1 from chat also)

RD: Don't need all the design thinking but simple primitives of "this is
what we want to do in extending JOSE". Complexity in charter won't help
us.

KO: Believe we have consensus to use initial charter as draft, MJ will
make edits and will leave a small window for additional suggestions.

JB: Summary: we will make these edits and then will present to the WG
after it is chartered.

RD: agree we have consensus, that we need wordsmithing. It will be
packaged on github. When MJ is done, I will put into datatracker and
then will put the pkg to the JOSE list to check consensus and accuracy.
Call for confirmation and then we'll take next steps (either more edits
or moving on to WG).

7. Proposed Mechanics (10 minutes)

KO: any objections to using the JOSE mailing list or to the WG being
JOSE

• JB: currently everyone working on this issue is today using the JOSE
  mailing list, so there would be inconvenience to change this
• Consensus call: If we end up with a WG, any objection to using the
  JOSE mailing list?
• No objections

Consensus call: objections to reopening the JOSE WG under the new
proposed charter?

• No objections

MJ: Propose to remove the TBD from charter and call it JOSE (no
objections)

• where should I send the amended charter?
• Chairs will do a quick check then send on

8. AOB (10 minutes)

RD: reminder of IETF process - after confirming consensus on the
charter, it goes to the IESG telechat for initial review, then to
community (2 weeks), then back to IESG for final review, and then WG.

• With the timing of the upcoming telechats, there is not enough time
  for this process to complete before London. Therefore, JOSE will not
  be a WG by London. Time is held on calendar for IETF 115 but RD will
  release the slot when the charter goes to the IESG. If it turns out
  there is a lot of contention and in-person charter discussions are
  needed, and the charter isn't with the IESG by London, then the
  booked London time can be used for that.

JB: could we use the time as an unofficial space or as a BOF?
RD: probably not

KO: does that mean side meetings can't happen?
RD: no, that is fine

KO: Wiki for side meetings open on Friday. JB and KO will work to get a
side meeting opened up. Meetecho support isn't there for side meetings.

RD: (in chat) a side meeting will be a sign of success