Hi Christian, Michael and I (as JOSE co-chairs) have taken a quick look at the document and this email thread, and we believe there is enough content and interest to merit a discussion in Vienna. We’ve allocated some agenda time for this in JOSE to at least get the ball rolling.
Thanks, Karen > On Jul 3, 2026, at 4:02 PM, Christian Bormann > <[email protected]> wrote: > > Dear JOSE & OAuth WG, > > Sorry for cross-posting, but this seems to be a topic that would fit both WGs > and cross-posting seemed to be the best way. > > I have submitted a new ID that proposes a digital credential format building > on top of JSON Web Proofs, SD-JWT VC, and blind BBS Signatures: > Datatracker: https://datatracker.ietf.org/doc/draft-bormann-jwp-modular-bbs/ > - GitHub: https://github.com/c2bo/draft-bormann-jwp-modular-bbs > > This document defines a digital credential format that uses JSON Web > Proofs (JWP) as its container format and Blind BBS Signatures as its > signature scheme combined with a modular framework for attaching > zero-knowledge sub-proofs. This allows a Holder to reveal some > attributes directly while proving predicates such as range or > equality over the ones they keep hidden. A credential can > additionally be bound to an ECDSA P-256 device key, with possession > of the key proven in every presentation without revealing the public > key. The credential type definition and data model follow SD-JWT VC > [I-D.ietf-oauth-sd-jwt-vc]. > > The core idea behind this draft is to enable a credential format that > functions similar to SD-JWT VC, but powered by a modular Anonymous > Credentials framework. > Instead of building on top of JWS/JWT, the container format is JWP (currently > JSON / compact serialisation only) and the core data model & credential type > system > of SD-JWT VC are re-used. The core signature mechanism is BBS, specifically > the blind BBS draft, since it adds committed disclosure - fresh Pedersen > commitments > to hidden messages at presentation time. > > The proposed construction allows for a digital credential format with > unlinkable presentations where each claim/value can individually be > > - hidden > - disclosed > - committed > > Commitments can then be used as inputs to chained sub-proofs (also called > Commit-and-Prove). This allows for sub-proofs like a range proof over > issuance or expiration time (proving that the credential is not expired > instead of disclosing the expiration time), or equality proofs (e.g., proving > two credentials > contain the same name without disclosing the value). The draft introduces a > registry and a few core sub-proofs, with one important sub-proof allowing for > a key > binding to a P-256 public key where a Zero Knowledge Proof of Knowledge over > a valid signature replaces the KB-JWT of SD-JWT. > The concrete constructions for these sub-proofs will be leveraged from > existing work (e.g., for range proofs) and the key binding sub-proof is > expected to be a > separate draft in CFRG: > https://datatracker.ietf.org/doc/draft-cllz-cfrg-ecdsa-pop/. > > The general idea for such a construction has been discussed for some time in > the context of EU Digital Identity Wallets / eIDAS and the draft roughly > follows the concepts of: > > - > https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md > - https://eprint.iacr.org/2025/1981 (Vision: A Modular Framework for > Anonymous Credential Systems) > > This is a rough first draft and especially the sub-proof parts definitely > need further work, but I’d love to get some feedback on the draft and the > general concept. > > Given the reliance on JWP for serialisation, I thought JOSE would be a > natural home, but since some parts of SD-JWT VC are re-used, there definitely > is an argument to be made for OAuth as well. Are people interested in this > kind of work and if so where should it happen? > > Happy to present the draft in Vienna if possible / still fits into the agenda. > > Best Regards, > Christian > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
