Wednesday, 12 October 2022, 1700 UTC
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.
What is a ZKP:
Very high level:
Today everyone designs their own custom containers. This limits
We can step up and create a multi-use solution without replacing
whole protocol infrastructure
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
There is a lot of interest in support for ZKP from many parties
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.
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
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.
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.
Questions about the clarity of the problem or whether there is a problem
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.
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.
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.
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
Is there a problem for the IETF to solve? 17 raised, 1 did not raised,
Consensus is there is a problem to solve.
Can the not-hand-raiser state why they didn't raise?
Was partly struggling with interface, there is a disconnect between the
problem and the proposal to solve it (i.e., the charter)
(in chat) agrees it is not clearly defined
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.
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
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.
Is there agreement that existing IETF work does not address this
Is there enough work here for a working group in the IETF?
Is there sufficient interest in doing this work?
Who is willing to participate? (Poll)
Who is willing to review? (Poll)
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
RD: Hearing we have to change charter but consensus check: is there
support for the deliverables as described in the charter?
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?
Peter Saint Andre: Question - charter says that there is talk of
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
Shawn Butterfield (SB): is it appropriate to reference SD-JWT?
MJ: there is a reference and intent to coordinate stated directly in the
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
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
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).
KO: any objections to using the JOSE mailing list or to the WG being
Consensus call: objections to reopening the JOSE WG under the new
MJ: Propose to remove the TBD from charter and call it JOSE (no
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.
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