# JOSE Working Group @ IETF 116 {#jose-working-group--ietf-116} 630 - 800 UTC (1530 - 1700 local time) Pacifico Yokohama: G316 ## Agenda {#agenda} ### Admin and Agenda Bash (Chairs - 5 minutes) {#admin-and-agenda-bash-chairs---5-minutes} Newly-reconsitited JOSE First meeting after a BoF in Phladelphia IETF! ### Charter review (Chairs - 10 minutes) {#charter-review-chairs---10-minutes} https://datatracker.ietf.org/wg/jose/about/ History of JOSE: what's been done and what that's lead to - signing, encryption, etc. - JSON Web tokens and other things that are adopted everywhere New context: applications that want to preserves privacy - existing structures don't support constructs that we need Current charter recap * Standards track documents on the signing, token, algs * four Standards track I-D track drafts exist (not yet WG adopted) * informal document for use cases and requirements for selective disclosure and zkp * no submissions to start on that yet * test vectors for all the above (and also COSE stuff) * chartered to work with W3C VCWG, privacy pass, sd-jwt (oauth WG), cbor, crfg Chairs requested to review the charter and suggest milestones. ### JSON Web Proof Drafts (Mike Jones - 30 minutes) {#json-web-proof-drafts-mike-jones---30-minutes} JSON Web Proofs https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-algorithms/ JSON Proof Algorithms https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-algorithms/ JSON Proof Token https://datatracker.ietf.org/doc/draft-jmiller-jose-json-proof-token/ #### Background {#background} BoF @ philadelphia meeting in July - discussed json web proofs - showed json-based container format for ZKP Overview of the above three specs * new container syntax, in the spirit of JOSE stack (JWS, JWE) * algorithms and c JSON web proof algorithms: * can selectively disclose subset of payloads * multiple presentations * prove predicates w/o disclosing payload values (ageOver18?) Originally bord in OIDF SIOP WG, incubated in DIF applied crypto WG, interest from W3C VC WG. * JWP <- JWS RFC7515 * JPA <- JWA (algs in their own draft) RFC7518 * JPT <- JWT RFC7519 #### Design Consideratons {#design-consideratons} selective disclosure: multiple payloads, so that subset can be disclosed unlinkability: proof of knowledge: want to account for multiple algs like BBS, ZkSNARKs, while also supporting currently available techniques like MAC. working with cryptographers #### Comparison of JWP and JWS {#comparison-of-jwp-and-jws} JWS has three parts: header, payload, signature JWP: looks a lot the same! * use the last remaining urlsafe character (tilde ~) to separate payloads from each other * three parts: header, payloads (plural), proof * JSON serialization also supported if a payload is omitted (not disclosed), placeholder concurrent tildes proposal: adopt jmiller drafts as starting points #### Discussion {#discussion} mike prorock: this is a good set of building blocks to start. Thanks Jeremie for the slides. mike jones: credits to CFRG for taking up algorithms for BBS Orie: excited for new work, especially URL safe representation part of it; and BBS and what it can do for privacy Tobias: supports the works, also having worked on BBS mike prorock: in addition to BBS, lots of work on the lattice side, still early but looks real * motivations: would be nice to have a way to have one signature set that we don't have to sign each individual element * work to date is from IBM, out to academia Brent Z: support bringing in these work items; volunteering to help write Orie: comment to add to what mike P said; lattice proofs have different hardness problem #### Adoption (chairs) {#adoption-chairs} chairs run poll, also humming: no opposed, strong in favor will be circulated on the list for final confirmation ### X.509 Certificate Extended Key Usage (EKU) for Javascript Object Signing and Encryption (Migault - 10 minutes) {#x509-certificate-extended-key-usage-eku-for-javascript-object-signing-and-encryption-migault---10-minutes} https://datatracker.ietf.org/doc/draft-reddy-lamps-jose-eku/ document submitted for LAMPS * document happens to have 'jose' in the title * presentation was intended for information * presenter not present ### Way Ahead and AOB (Chairs - 5 minutes) {#way-ahead-and-aob-chairs---5-minutes} milestone defined today: * adopt drafts by july use-case doc * JohnB: is there a will to define a use-case document? was important to put into the charter * Justin: use-case documents are important to get WG on the same page, but they tend to become less relevant as the work progresses, and start taking energy away from the WG. Suggestion: informal, non-deliverable, wiki-page level use-case document. How Roman would like to do it? * Roman: Chartered to do use-case document. we can revisit. cannot put informational document in a wiki. and do not need to decide this now * heckler: no WG has ever failed to deliver a milestone * Chair: can start working on an informational document and not publish * carsten: introduction to actual spec usually has some use cases * the WG is just starting, this will remain an open item. scope of the WG * MikeP: question on the milestones. there is a draft in -03 in another WG (quantum resistant COSE algs) that should belog to this WG. clarification: things that are not exactly zkp, but can benefit from a work in this WG * JohnB: not defining algs, but representations in this WG. we should have a container format that can support those new algs, instead for asking splitting already existing document, and it is not a question of which WG * roman: JOSE maintenance of a work that is not related to zkp/sd should be done in this WG. * MikeJ: test suites. Jeremie has been great about having a running code. * Carsten: more hollistic test vectors are needed; in GH repo. and they can be done orthogonally from the spec * Justin: one of the most useful tools in JOSE community is , not a document from a WG. would encourage this WG to think outside the core specification - what will be useful for the community. another example is tooling: GH? * docs are already in GH repo, started that way @ DIF * editors want to keep the same repo * Carsten: recommends creating a WG org repository and moving an old GH repo to that org. you don't lose links when moving. * Justin: not doing what Carsten suggested would be ridiculous. main thing is to enforce chairs control and to use IETF tools. * chairs: no strong opinion from the chairs. just want a WG decision. Bottomline, don't want to lose momentum * MikeJ: no existing JOSE GH repo * David Waite: no objections moving GH repos virtual interims * Jeremie: would like to see how fast we can progress via GH and mailing list. if not enough progress by the next ietf, let's consider virtual BoFs. No other AOB. meeting ajourned.