Skip to main content

Minutes IETF116: jose: Mon 06:30
minutes-116-jose-202303270630-00

Meeting Minutes Javascript Object Signing and Encryption (jose) WG
Date and time 2023-03-27 06:30
Title Minutes IETF116: jose: Mon 06:30
State Active
Other versions markdown
Last updated 2023-07-18

minutes-116-jose-202303270630-00

JOSE Working Group @ IETF 116

630 - 800 UTC (1530 - 1700 local time)
Pacifico Yokohama: G316

Agenda

Admin and Agenda Bash (Chairs - 5 minutes)

Newly-reconsitited JOSE

First meeting after a BoF in Phladelphia IETF!

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 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

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.

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

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

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)

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)

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)

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.