# JSON Web Proofs (JWP) Virtual Interim BOF {#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) {#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) {#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) {#3-discussion-of-the-problem-15-minutes} ### Brent Zundel {#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 {#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 {#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 {#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 {#karen-odonaghue} Questions about the clarity of the problem or whether there is a problem to solve? ### Brian Campbell (BC) {#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) {#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) {#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 {#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: {#poll} Is there a problem for the IETF to solve? 17 raised, 1 did not raised, 18 participants ### Karen O'Donaghue {#karen-odonaghue-1} Consensus is there is a problem to solve. ### Carsten Bormann (CB) {#carsten-bormann-cb} Can the not-hand-raiser state why they didn't raise? ### Brian Campbell {#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 {#carsten-bormann} (in chat) agrees it is not clearly defined ## 4. How are we proposing to address this problem? (Jeremie - 15 minutes) {#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) {#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) {#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) {#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) {#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