Return-Path: X-Original-To: jose@mail2.ietf.org Delivered-To: jose@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DE72611035E7E; Mon, 6 Jul 2026 07:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783347011; bh=WrWnL3Dx6BGjeVNwc0dTSur2OoQAf6vxIKAKptDknrM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=KXPa5J9w9csjl3W31UcCVCL4CjW2Eme26IEagbFw2CApSQmSksRRk9CRWjL9T2r9r UKSVe3EXUpc9l2I55gd+llijB1SO9UNrXSiLybTXmdrXxRNx+DSBets8/AxZfPhZ0z BiwyzU2sWgT0lvfjh3IqiISZXBmGxoCRb0ZQI+qM= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=alkaline-solutions.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr7AG-80hmUf; Mon, 6 Jul 2026 07:10:10 -0700 (PDT) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0DE8011031F14; Mon, 6 Jul 2026 07:02:30 -0700 (PDT) From: David Waite DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1783346534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h10P4n3ZILWH5/p1gVhatgIN3L3rNDLzZlUyq5H1VZ4=; b=rtNGM1AkWgo5KpIzHW+4SRrSLk7Bl5SBL4YpAXl4+JlsOWC59BVsL6DBHlIxZp0Dty+cr+ ofwfhDX2J1NdGYws5+CaYqYq7cK431k45E7U42ZtEZ0BgXJkNX/n89qxqPIsutWereuxOA RnprOTJ7YrfhwQ45IFt4iYT3K+3tFsMf1NEGY/DMoYlZ4FJFMhVfLgyZbM+GhNup6NlT+w +Q8ciQAE6cOsXst2nl4o4Fse+3NsQm41rS9jk75B/gOyoYZULsoFBj7Eq8J0wx/sPFxykr qqVkr7Nb5/jqxEBS8o9AFKW5l/mhY9tFUmSZ0l9Y4f1v6Zc8oyP0LrGJjA74rQ== Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com Message-Id: <0AE12CC6-108D-4F55-BEA4-B16EA7642FB4@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_213394FC-2827-44D8-BC56-4A4CC06C0B4C" Mime-Version: 1.0 Date: Mon, 6 Jul 2026 08:00:00 -0600 In-Reply-To: <00CEC1D1-A817-4517-9B10-74B26D6D2F39@gmx.de> To: Christian Bormann References: <178283255465.2087397.4256787017301844320@dt-datatracker-f9b87776f-xzl65> <00CEC1D1-A817-4517-9B10-74B26D6D2F39@gmx.de> X-Spamd-Bar: -- Message-ID-Hash: 56PSXNSITCNU2TELPYDQUTGOQHR4J6KE X-Message-ID-Hash: 56PSXNSITCNU2TELPYDQUTGOQHR4J6KE X-MailFrom: david@alkaline-solutions.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: jose@ietf.org, oauth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_=5BOAUTH-WG=5D_New_I-D=3A_draft-bormann-jwp-modul?= =?utf-8?q?ar-bbs?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_213394FC-2827-44D8-BC56-4A4CC06C0B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Christian - I=E2=80=99m excited to see this work! Some initial comments and questions from a brief read (in no semblance = of priority order:) 1. The new =E2=80=9Ccmap=E2=80=9D issuer header has overlap with the = =E2=80=9Cclaims=E2=80=9D header in JPT. I notice one significant = difference is a document substitution/structural mapping approach to = support sub-claims - rather than using a path/pointer primitive to = define the name of each top level claim or sub-claim, it replicates a = claim/sub-claim tree and provides positional metadata. This somewhat surprised me, as the sd-jwt vc draft = (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html#name-e= xample-2) and OpenID4VP ( = https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-c= laims-path-pointer ) both seem to use more of a pointer syntax to = decompose the document. While not yet published, I have been working = based on feedback that this is more of the direction that implementors = preferred, so I=E2=80=99m curious if there was a particular set of = motivations to go with the =E2=80=9Ccmap" format. Ideally I think I would like to see a credential profiling of JPT, = analogous to the SD-JWT VC work. That would motivate me to push for one = of =E2=80=9Ccmap=E2=80=9D or =E2=80=9Cclaims=E2=80=9D that can bend to = support both generalized JPT and specific credential use cases, = including the usage here. 2. The scalar encoding is defined as an ASCII decimal encoding of the = integer value. I have two related observations here: 2a. When operating in scalar=3Dtrue mode, I=E2=80=99m curious why this = is not an I2OSP big-endian representation of the integer value. JSON = numbers are a complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues. 2b. I=E2=80=99m curious whether it is worth limiting scalar claim values = as defined here to uint64, when they are meant to be disclosable data.=20= I have not designed these proof constructions myself, so I may be = missing something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal encoding. 3. The encoding for the device binding key is little endian, which = surprised me considering both BBS and P-256 are big endian. Any = elaboration on the motivation behind this decision? 4. For decoys, I assume JWP-BBS-DECOY was chosen partially because it = isn=E2=80=99t a legal JSON Text value. Would it make sense if the = scalar=3Dtrue alternative was also defined to be a fixed, not valid = value that e.g. proofs could be written to check against? 5. Device binding hits a case I hadn=E2=80=99t thought of, partly = because I hadn=E2=80=99t considered a case for payloads both being = candidates for disclosure and for commitments - that a conceptual = payload might need to be represented over more than one slot. Is = reserving space at a particular offset (e.g. the first four scalars) = going to be appropriate? For example, is there a potential for a = credential to be issued with more than one key encoded into it? 6. For sub-proofs, my suspicion is that the metadata/setup would be = encoded into the presentation header, while the actual proof values = would be part of the presentation proofs sequence. Is that your = expectation as well? 7. The draft currently says that the =E2=80=9Ckb=E2=80=9D device binding = header must be present to denote that there are slots reserved for = holding the key, but also that the key MUST be asserted via a sub-proof. = Baking this usage policy in seems limiting, but I have not yet come up = with a concrete example to back that up. 8. For sub-claims in particular, I=E2=80=99m noodling over whether this = would be feasible to have in JWP rather than as an algorithm-specific = feature - partly because I could see other algorithms wanting an = identical facility in the future. There might be some commonality in how = the constructions work across some algorithms, but certainly not all - = and I suspect differences might be hard to reconcile at the presentation = header level (such as equality taking a BBS12-381 G1 point as input). We = could specify specifically e.g. range-proof for BBS-MOD in a single = registry, but=20 I haven=E2=80=99t figured out if there=E2=80=99s a way to encourage = commonality or if that is just mapping out an overlapping namespace. 9. With the exclusion of the device binding claim above, it appears all = sub-claim usage is opt-in - such that a holder can support verifiers = with differing capabilities without needing different credentials. This = was a concern of mine with the BBS extensions published so far, and = I=E2=80=99m delighted to see this. -DW =20 > On Jul 3, 2026, at 2:02=E2=80=AFPM, Christian Bormann = wrote: >=20 > Dear JOSE & OAuth WG, >=20 > 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. >=20 > 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=20 >=20 > 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]. >=20 > 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. >=20 > The proposed construction allows for a digital credential format with = unlinkable presentations where each claim/value can individually be >=20 > - hidden > - disclosed > - committed=20 >=20 > 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/.=20 >=20 > 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: >=20 > - = https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-techn= ical-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)=20 >=20 > This is a rough first draft and especially the sub-proof parts = definitely need further work, but I=E2=80=99d love to get some feedback = on the draft and the general concept. >=20 > 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? >=20 > Happy to present the draft in Vienna if possible / still fits into the = agenda. >=20 > Best Regards, > Christian > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org --Apple-Mail=_213394FC-2827-44D8-BC56-4A4CC06C0B4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Christian - I=E2=80=99m excited to = see this work!

Some initial comments and questions = from a brief read (in no semblance of priority = order:)

1. The new =E2=80=9Ccmap=E2=80=9D = issuer header has overlap with the =E2=80=9Cclaims=E2=80=9D header in = JPT. I notice one significant difference is a document = substitution/structural mapping approach to support sub-claims - rather = than using a path/pointer primitive to define the name of each top level = claim or sub-claim, it replicates a claim/sub-claim tree and provides = positional metadata.

This somewhat surprised = me, as the sd-jwt vc draft (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-v= c-13.html#name-example-2) and OpenID4VP ( https://openid.net/specs/openid-4-verifiable-p= resentations-1_0.html#name-claims-path-pointer ) both seem to = use more of a pointer syntax to decompose the document. While not yet = published, I have been working based on feedback that this is more of = the direction that implementors preferred, so I=E2=80=99m curious if = there was a particular set of motivations to go with the =E2=80=9Ccmap" = format.

Ideally I think I would like to see a = credential profiling of JPT, analogous to the SD-JWT VC work. That would = motivate me to push for one of =E2=80=9Ccmap=E2=80=9D or =E2=80=9Cclaims=E2= =80=9D that can bend to support both generalized JPT and specific = credential use cases, including the usage = here.

2. The scalar encoding is defined as = an ASCII decimal encoding of the integer value. I have two related = observations here:

2a. When operating in = scalar=3Dtrue mode, I=E2=80=99m curious why this is not an I2OSP = big-endian representation of the integer value. JSON numbers are a = complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues.

2b. I=E2=80=99m curious whether it is = worth limiting scalar claim values as defined here to uint64, when they = are meant to be disclosable data. 

I have = not designed these proof constructions myself, so I may be missing = something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal = encoding.

3. The encoding for the device = binding key is little endian, which surprised me considering both BBS = and P-256 are big endian. Any elaboration on the motivation behind this = decision?

4. For decoys, I assume JWP-BBS-DECOY = was chosen partially because it isn=E2=80=99t a legal JSON Text value. = Would it make sense if the scalar=3Dtrue alternative was also defined to = be a fixed, not valid value that e.g. proofs could be written to check = against?

5. Device binding hits a case I = hadn=E2=80=99t thought of, partly because I hadn=E2=80=99t considered a = case for payloads both being candidates for disclosure and for = commitments - that a conceptual payload might need to be represented = over more than one slot. Is reserving space at a particular offset (e.g. = the first four scalars) going to be appropriate? For example, is there a = potential for a credential to be issued with more than one key encoded = into it?

6. For sub-proofs, my suspicion is = that the metadata/setup would be encoded into the presentation header, = while the actual proof values would be part of the presentation proofs = sequence. Is that your expectation as well?

7. = The draft currently says that the =E2=80=9Ckb=E2=80=9D device binding = header must be present to denote that there are slots reserved for = holding the key, but also that the key MUST be asserted via a sub-proof. =  Baking this usage policy in seems limiting, but I have not yet = come up with a concrete example to back that = up.

8. For sub-claims in particular, I=E2=80= =99m noodling over whether this would be feasible to have in JWP rather = than as an algorithm-specific feature - partly because I could see other = algorithms wanting an identical facility in the future. There might be = some commonality in how the constructions work across some algorithms, = but certainly not all - and I suspect differences might be hard to = reconcile at the presentation header level (such as equality taking a = BBS12-381 G1 point as input). We could specify specifically e.g. = range-proof for BBS-MOD in a single registry, = but 
I haven=E2=80=99t figured out if there=E2=80=99s= a way to encourage commonality or if that is just mapping out an = overlapping namespace.

9.  With the = exclusion of the device binding claim above, it appears all sub-claim = usage is opt-in - such that a holder can support verifiers with = differing capabilities without needing different credentials. This was a = concern of mine with the BBS extensions published so far, and I=E2=80=99m = delighted to see = this.

-DW

 


On Jul 3, = 2026, at 2:02=E2=80=AFPM, Christian Bormann = <chris.bormann=3D40gmx.de@dmarc.ietf.org> 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: h= ttps://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://eprint.iacr.org/2025/19= 81 (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=E2=80=99= 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
____= ___________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to = oauth-leave@ietf.org

= --Apple-Mail=_213394FC-2827-44D8-BC56-4A4CC06C0B4C--