TODO Working Group C. Bormann Internet-Draft SPRIND GmbH Intended status: Standards Track 30 June 2026 Expires: 1 January 2027 BBS and Modular Sub-proofs with JSON Web Proofs draft-bormann-jwp-modular-bbs-00 Abstract 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 to signed but undisclosed attributes that allow a Holder to reveal some attributes directly while proving predicates such as range or equality over the ones they keeps hidden. A credential can additionally be bound to an ECDSA P-256 device key. The credential metadata and type model follow SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the JSON Web Proofs Working Group mailing list (jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/jose/. Source for this draft and an issue tracker can be found at https://github.com/c2bo/draft-bormann-jwp-modular-bbs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 January 2027. Bormann Expires 1 January 2027 [Page 1] Internet-Draft JWP-BBS June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 4 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 4 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Issued Credential . . . . . . . . . . . . . . . . . . . . 5 2.2. Issuer Header . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Claims Mapping . . . . . . . . . . . . . . . . . . . . . 6 2.4. Example: Issuance . . . . . . . . . . . . . . . . . . . . 6 2.5. Message Derivation . . . . . . . . . . . . . . . . . . . 8 2.6. Scalar Encoding . . . . . . . . . . . . . . . . . . . . . 9 2.7. Temporal Claims . . . . . . . . . . . . . . . . . . . . . 9 2.8. Device Binding Header . . . . . . . . . . . . . . . . . . 9 2.9. Structural Layout . . . . . . . . . . . . . . . . . . . . 10 2.10. Decoys . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Issuance . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Issuer Key Generation . . . . . . . . . . . . . . . . . . 10 3.2. Credential Issuance . . . . . . . . . . . . . . . . . . . 11 3.3. Holder Verification . . . . . . . . . . . . . . . . . . . 11 4. Presentation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Presented Form . . . . . . . . . . . . . . . . . . . . . 11 4.2. Presentation Header . . . . . . . . . . . . . . . . . . . 12 4.3. Core Proof . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Sub-Proofs . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. ECDSA Device-Binding Sub-Proof . . . . . . . . . . . 14 4.4.2. Range Proof Sub-Proof . . . . . . . . . . . . . . . . 15 4.4.3. Equality Proof Sub-Proof . . . . . . . . . . . . . . 16 4.5. Example Presentation . . . . . . . . . . . . . . . . . . 16 4.6. Reconstructed JSON Payload . . . . . . . . . . . . . . . 17 5. Cipher Suite . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 18 Bormann Expires 1 January 2027 [Page 2] Internet-Draft JWP-BBS June 2026 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. Random Number Generation . . . . . . . . . . . . . . . . 19 6.2. Hash-to-Scalar Bypass . . . . . . . . . . . . . . . . . . 19 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Issuer Header Correlation . . . . . . . . . . . . . . . . 19 7.2. Cipher Suite and Algorithm Identifiers . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.1. JPA alg Value . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Header Parameter Registrations . . . . . . . . . . . . . 20 8.3. Sub-Proof Algorithms Registry . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix B. Document History . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The BBS signature scheme [I-D.irtf-cfrg-bbs-signatures] is a multi- message signature (MMS) scheme where the signer produces a single signature over a vector of messages m_0 through m_(n-1), and the Holder can prove knowledge of the signature in zero knowledge while disclosing only a chosen subset of those messages. The Blind BBS Signatures extension [I-D.irtf-cfrg-bbs-blind-signatures] adds Pedersen commitments to the scheme that allow the Holder to mark each message as disclosed, hidden, or committed at proof time, and the resulting proof carries a fresh Pedersen commitment for every committed message. Those commitments become public inputs to further proofs over the values they hide. Building on those core building lbocks, this document defines a digital credential format that: * Uses JSON Web Proofs [I-D.ietf-jose-json-web-proof] as the serialization/container format for both issuance and presentation, and defines a JSON Proof Algorithm [I-D.ietf-jose-json-proof-algorithms] profile based on Blind BBS Signatures. * Builds its core proof on CoreProofGen of [I-D.irtf-cfrg-bbs-blind-signatures], exposing fresh Pedersen commitments to selected messages as public inputs for sub-proofs. * Defines a sub-proof container carrying optional sub-proofs, each bound to the core proof via a Pedersen commitment. * Optionally bind a credential to an ECDSA P-256 device key by encoding that key as messages in the BBS signature vector. Bormann Expires 1 January 2027 [Page 3] Internet-Draft JWP-BBS June 2026 This modular architecture builds on prior work [TS14] and [LSZ25], and the credential type and metadata model are reused from SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. 1.1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Notational Conventions All examples in this document are non-normative. Indexing into vectors is 0-based. The notation m_i denotes the i-th element of the message vector: m_0 is the first element. Ranges are written [a, b] for inclusive endpoints and [a, b) for a half-open interval. 1.3. Terms and Definitions This document uses the Issuer-Holder-Verifier model and terminology of [I-D.ietf-oauth-sd-jwt-vc]. Additional terminology used are: Core proof: A zero-knowledge proof of knowledge of a BBS signature on a message vector, where some messages are disclosed and others are exposed only as commitments. Sub-proof: A zero-knowledge proof attached to a core proof, asserting a predicate over a message whose Pedersen commitment that core proof exposes. Committed disclosure: Exposing a Pedersen commitment to a signed message in place of the value itself that is used as an input for sub-proofs. Device binding: Tying a credential presentation to control of a Holder-held private key, by carrying a fresh proof of possession in every presentation. 2. Data Model A credential exists in two forms: the Issued Form an Issuer transmits to a Holder, and the Presented Form a Holder derives from it for a Verifier (see Section 4). Bormann Expires 1 January 2027 [Page 4] Internet-Draft JWP-BBS June 2026 2.1. Issued Credential A credential is issued in the Issued Form (see Section 6.1 of [I-D.ietf-jose-json-web-proof]) consisting of: * An Issuer Header (Section 6.1.1 of [I-D.ietf-jose-json-web-proof]) with the contents specified in Section 2.2. * n Issuer Payloads (Section 6.1.2 of [I-D.ietf-jose-json-web-proof]), where n is the length of the BBS message vector (see Section 2.3). The Issuer Payload at position i is the octet string from which the scalar message m_i is derived per Section 2.5. * An Issuer Proof (Section 6.1.3 of [I-D.ietf-jose-json-web-proof]) carrying the blind BBS signature over header_octets and the message vector (m_0, ..., m_(n-1)). header_octets is the Issuer Header as transmitted, i.e., the octets obtained by base64url-decoding the Issuer Header component of the Compact Serialization. All parties MUST use those octets as received and MUST NOT alter the header (e.g., re-encode). The Issued Form is serialized using the Compact Serialization (Section 7.1 of [I-D.ietf-jose-json-web-proof]). CBOR Serialization is (currently) out of scope for this document. 2.2. Issuer Header The Issuer Header is a JSON object with the following Header Parameters. alg (REQUIRED): The Algorithm Header Parameter (Section 5.2.1 of [I-D.ietf-jose-json-web-proof]). This profile defines the JPA value BBS-MOD (see Section 5). vct (string, REQUIRED): The credential type identifier as defined in Section 3.2.2.1 of [I-D.ietf-oauth-sd-jwt-vc]. claims (JSON object, REQUIRED): The mapping from claim names to message-vector positions and per-message encoding - see Section 2.3 for more details. kb (string, OPTIONAL): The device-binding identifier - see Section 2.8. When absent, the credential is not device-bound, and a presentation MUST NOT include a device-binding sub-proof. Temporal claims (exp, nbf, iat) MUST NOT appear as Issuer Header values - see Section 2.7 for more details. The JWP iek, hpk, and hpa Header Parameters (Sections 5.2.5–5.2.7 of [I-D.ietf-jose-json-web-proof]) MUST NOT appear in the Issuer Header. Bormann Expires 1 January 2027 [Page 5] Internet-Draft JWP-BBS June 2026 2.3. Claims Mapping claims mirrors the credential's JSON tree structurally. Each leaf is replaced by an index annotation: a two-element JSON array [i, scalar], where: * i is the 0-based index of the leaf value in the message vector. * scalar is a boolean selecting how the leaf becomes the BBS message m_i: - false: the leaf is encoded as octets and mapped to a scalar via the cipher suite's hash-to-scalar primitive (see Section 2.5). - true: the leaf MUST be a JSON integer in [0, r - 1] (where r is the order of the BBS scalar field) and is used directly as m_i (see Section 2.6). Let n be the length of the message vector, and N the number of payload slots reserved for the device-key encoding (see Section 2.8), with N = 0 when kb is absent). Every index in [N, n-1] MUST appear in exactly one annotation in claims. Indices [0, N-1] MUST NOT appear in claims. Payload slots defined by the credential type's structural layout (see Section 2.9) but not populated by a given credential MUST carry the decoy value defined in Section 2.10. 2.4. Example: Issuance Starting from an SD-JWT VC-style claim set [I-D.ietf-oauth-sd-jwt-vc]: Bormann Expires 1 January 2027 [Page 6] Internet-Draft JWP-BBS June 2026 { "vct": "https://credentials.example.com/identity_credential", "given_name": "Erika", "family_name": "Mustermann", "email": "erika@example.com", "phone_number": "+49 123456789", "address": { "street_address": "Heidestraße 17", "locality": "Köln", "region": "Nordrhein-Westfalen", "country": "DE" }, "birthdate": "19630812", "is_over_18": true, "is_over_21": true, "is_over_65": false, "iat": 1683000000, "exp": 1786000000 } The vct claim becomes a Header Parameter and the other 14 attributes become leaves in claims, with address mirrored as a nested object. No device binding is used, so N = 0 and the leaves occupy indices 0 through 13. The temporal claims iat and exp are carried as scalar = true leaves (see Section 2.7) to allow range sub-proofs over them. The resulting Issuer Header is: Bormann Expires 1 January 2027 [Page 7] Internet-Draft JWP-BBS June 2026 { "alg": "BBS-MOD", "vct": "https://credentials.example.com/identity_credential", "claims": { "given_name": [0, false], "family_name": [1, false], "email": [2, false], "phone_number": [3, false], "address": { "street_address": [4, false], "locality": [5, false], "region": [6, false], "country": [7, false] }, "birthdate": [8, false], "is_over_18": [9, false], "is_over_21": [10, false], "is_over_65": [11, false], "iat": [12, true], "exp": [13, true] } } Indices 0–11 use hash-to-scalar and indices 12–13 carry NumericDate integers ([RFC7519]) directly as scalars. A presentation can then mark iat/exp as COMMIT (see Section 4.3) and attach sigma-range sub- proofs (see Section 4.4.2) to prove validity without disclosing the timestamps. A real deployment would define a structural layout covering all optional attributes and array slots up to their maximum length, with absent slots filled by decoys (see Section 2.10). 2.5. Message Derivation For an annotation [i, false] with leaf value v: 1. The Issuer chooses an octet encoding o of v (e.g., the UTF-8 octets of a string) and carries it as Issuer Payload i. This profile does not mandate a specific encoding. Holders MUST use the received payload octets as-is. 2. m_i = hash_to_scalar(o, map_dst), with map_dst = api_id || "MAP_MSG_TO_SCALAR_AS_HASH_" and api_id the Interface identifier of Section 5. This is the per-message derivation of BBS.messages_to_scalars (Section 4.1.2 of [I-D.irtf-cfrg-bbs-signatures]). For an annotation [i, true] with leaf value v: Bormann Expires 1 January 2027 [Page 8] Internet-Draft JWP-BBS June 2026 1. o is the canonical decimal octet encoding of v (see Section 2.6), carried as Issuer Payload i. 2. m_i is the integer denoted by o, interpreted as an element of the BBS scalar field. 2.6. Scalar Encoding A leaf with scalar = true MUST be a JSON integer in [0, r - 1], where r is the order of the BBS scalar field. Implementations MUST reject any other value. The Issuer Payload for such a leaf is the canonical decimal octet encoding of the integer. Future extensions MAY define additional scalar encodings provided they deterministically map a JSON value to an element of [0, r - 1]. 2.7. Temporal Claims The JWT temporal claims exp, nbf, and iat (Section 4.1 of [RFC7519]), when present in a credential, MUST be declared as scalar = true leaves in claims carrying their NumericDate values. They MUST NOT appear as Issuer Header values. 2.8. Device Binding Header When present, the kb Header Parameter is a string identifier selecting both the device public key type and its encoding into the BBS message vector. The reserved slots are always indices [0, N-1], where N depends on the kb value. If kb is not present, no slots are reserved. This document defines a single value for kb: ecdsa- p256-db. A kb value and its matching device-binding sub-proof algorithm (see Section 4.4) share the same algorithm identifier string. For kb = "ecdsa-p256-db", N = 4 and: * m_0..m_1 encode the x-coordinate of the device public key as two 128-bit little-endian limbs (m_0 least significant). * m_2..m_3 encode the y-coordinate the same way. Each limb is encoded as if scalar = true: the Issuer Payload is its canonical decimal octet encoding (see Section 2.6). The Issuer MUST make sure that (x, y) is a valid non-identity P-256 point [FIPS186-5] before computing the message vector. Bormann Expires 1 January 2027 [Page 9] Internet-Draft JWP-BBS June 2026 2.9. Structural Layout For claims containing objects, the Issuer either mirrors the object structure within claims or treats the JSON-encoded object as a single leaf. This is a policy decision by the Issuer and allows some objects to be discloseable only as one object containing all values or not at all. For bounded-length array claims, claims contains a JSON array of index annotations sized to the credential type's maximum array length. All entries in such an array SHOULD share the same scalar flag to guarantee a single decoy encoding (see Section 2.10). For optional claims, claims MUST contain the index entry regardless of whether the attribute is present in a given credential. 2.10. Decoys Decoys fill payload slots that the credential type's layout defines, but a specific credential does not populate. They keep the message- vector length and claims identical across all credentials of a given vct to avoid correlation. Every decoy slot carries the same fixed scalar: m_decoy = hash_to_scalar("JWP-BBS-DECOY", map_dst) with hash_to_scalar and map_dst as defined in Section 2.5. The Issuer Payload for a decoy slot depends on the slot's scalar flag: * scalar = false: the ASCII octets of "JWP-BBS-DECOY". * scalar = true: the canonical decimal octet encoding of m_decoy (see Section 2.6). A Verifier detects a disclosed decoy by comparing the disclosed Presentation Payload octets to the fixed decoy octets defined above. Decoys SHOULD NOT be disclosed unless required by the use case (for example, a proof over all members of a bounded-length array). 3. Issuance 3.1. Issuer Key Generation The Issuer key pair is a BBS key pair (Section 3.4 of [I-D.irtf-cfrg-bbs-signatures]) using the cipher suite of Section 5. Bormann Expires 1 January 2027 [Page 10] Internet-Draft JWP-BBS June 2026 3.2. Credential Issuance To issue a credential, the issuer performs the following steps: 1. Construct the Issuer Header per Section 2.2 and Section 2.3. 2. Derive the message vector (m_0, ..., m_(n-1)) per Section 2.5 and Section 2.8, filling decoys per Section 2.10. 3. Compute the blind BBS signature over header_octets and the message vector. 4. Assemble and serialize the Issued Form per Section 2.1. A non-normative example of the Compact Serialization: . ~~ ... ~ . Each is the base64url-encoded Issuer Payload for index i (e.g., m_1 is "Mustermann", m_13 is 1786000000). 3.3. Holder Verification The Holder verifies an issued credential by: 1. Parsing the Issued Form. 2. Verifying the blind BBS signature over header_octets and the message vector. Reject on failure. 3. For every scalar = true leaf, confirming the corresponding Issuer Payload decodes to an integer in [0, r - 1]. 4. If kb is present, confirming that the point reconstructed from the limb messages matches the Holder's device public key. How the Holder obtains the corresponding device key pair is out of scope. 4. Presentation 4.1. Presented Form A presentation is a Presented Form (Section 6.2 of [I-D.ietf-jose-json-web-proof]) consisting of: 1. A Presentation Header per Section 4.2. 2. The Issuer Header from issuance, byte-identical to the issued form. Bormann Expires 1 January 2027 [Page 11] Internet-Draft JWP-BBS June 2026 3. n Presentation Payloads (Section 6.2.2 of [I-D.ietf-jose-json-web-proof]): disclosed positions carry the corresponding Issuer Payload and undisclosed positions are omitted (see Section 7.1 of [I-D.ietf-jose-json-web-proof]). 4. A Presentation Proof (Section 6.2.4 of [I-D.ietf-jose-json-web-proof]) consisting of one or more octet strings. The first octet string is the encoded core proof (see Section 4.3). Subsequent octet strings, if any, are UTF-8 JSON- serialized sub-proof objects (see Section 4.4) and MAY appear in any order. The Compact Serialization base64url-encodes each octet string. 4.2. Presentation Header The Presentation Header is a JSON object with the following Header Parameters. nonce (string, REQUIRED): The Nonce Header Parameter (Section 5.2.10 of [I-D.ietf-jose-json-web-proof]). aud (string, REQUIRED): The Audience Header Parameter (Section 5.2.9 of [I-D.ietf-jose-json-web-proof]). Additional Header Parameters MAY be present, but their use is out of scope for this document. presentation_header_octets is the Presentation Header as transmitted, i.e., the octets obtained by base64url-decoding the Presentation Header component of the Compact Serialization. It is bound into the core proof challenge (see Section 4.3). Verifiers MUST use those octets as received. 4.3. Core Proof The Holder builds a per-message disclosure map assigning each index in [N, n-1] (where N is as in Section 2.3) one of DISCLOSE, HIDE, or COMMIT: * DISCLOSE: the message is revealed and its value MUST match the corresponding disclosed Presentation Payload. * COMMIT: a fresh Pedersen commitment to the message is carried in the proof. Every index referenced by a sub-proof (see Section 4.4) MUST be marked COMMIT. * HIDE: all other indices in [N, n-1]. Device-key indices [0, N-1] are implicitly hidden. The Holder generates the core proof by invoking CoreProofGen of [I-D.irtf-cfrg-bbs-blind-signatures] with: Bormann Expires 1 January 2027 [Page 12] Internet-Draft JWP-BBS June 2026 * PK: Issuer public key. * signature: blind BBS signature from the Issuer Proof. * header: header_octets. * ph: presentation_header_octets (binds nonce and aud into the challenge). * messages: (m_0, ..., m_(n-1)). * disclosed_indexes: indices marked DISCLOSE. * commits_indexes: indices marked COMMIT. * api_id: the cipher suite identifier of Section 5. CoreProofGen returns (proof, add_zkp_info). add_zkp_info contains, per committed index, the Pedersen commitment C_i and the blinding scalar s_i. The Holder retains it locally to build sub-proofs and MUST NOT transmit it. Only proof is carried as the first octet string of the Presentation Proof. The core proof establishes that the Holder knows a blind BBS signature under the Issuer's public key on a message vector whose disclosed-index values match the disclosed Presentation Payloads, and that each carried C_i commits to the message at index i of that vector. The Verifier verifies the core proof with CoreProofVerify, passing PK, the core proof, header_octets, presentation_header_octets, the disclosed scalar messages, and api_id. The disclosed and committed indices are recovered from the proof octets, not passed separately. On success, the Verifier recovers the committed indices and the corresponding C_i from the proof octets which are used in the sub- proof verification (see Section 4.4). 4.4. Sub-Proofs A sub-proof is a JSON object carried as an additional octet string of the Presentation Proof (see Section 4.1) with the following members: alg (string, REQUIRED): The sub-proof algorithm identifier from the Sub-Proof Algorithms registry (see Section 8). input (JSON object, REQUIRED): Public inputs to the sub-proof. MUST contain i and MAY contain algorithm-specific members. i is a non-empty JSON array of message-vector indices, each of which MUST be a COMMIT-marked index of the core proof. Each algorithm fixes the length of i and the role of its entries. proof (string, REQUIRED): The base64url [RFC4648] encoding of the sub-proof bytes specified by alg. Bormann Expires 1 January 2027 [Page 13] Internet-Draft JWP-BBS June 2026 For each sub-proof, the Verifier MUST confirm that every value in i is among the committed indices recovered from the core proof, and MUST then run the algorithm-specific verification routine against the corresponding C_i, input, and proof. Sub-proof freshness is inherited from the core proof: every C_i is randomized per presentation, and the core proof's challenge binds to presentation_header_octets. Sub-proof algorithms that include public material not derived from C_i (for example, the device ECDSA signature in ecdsa-p256-db) MUST bind that material to the current presentation by other means (ecdsa-p256-db does so via db_msg - see Section 4.4.1). Sub-proof transcripts use the BBS encoding primitives of Section 4.2.4.1 of [I-D.irtf-cfrg-bbs-signatures]: BLS12-381 G1 points are serialized in their compressed form (48 octets), scalars as 32-octet big-endian integers, and integer lengths are encoded as I2OSP(int, 8). The serialize(...) notation used in Section 4.4.2 and Section 4.4.3 denotes the concatenation of these per-element encodings. [Editor's Note: Some of the following sub-proofs already make very concrete choices to make the construction more concrete - all of these are open for discussion and will very like see significant changes.] 4.4.1. ECDSA Device-Binding Sub-Proof This sub-proof MUST be present whenever kb = "ecdsa-p256-db" and MUST NOT be present otherwise. The algorithm identifier deliberately matches the kb value it verifies (see Section 2.8). Algorithm identifier: ecdsa-p256-db Inputs (beyond the base sub-proof fields): none. The i field MUST be [0, 1, 2, 3], naming the four indices that carry the device public- key limbs (see Section 2.8). The device-signed message is not transmitted, it is recomputed as: db_msg = "JWP-BBS-DB-CHAL" || presentation_header_octets where "JWP-BBS-DB-CHAL" is the literal ASCII string. Binding db_msg to presentation_header_octets carries nonce and aud and is therefore sufficient for freshness. The proof bytes encode a non-interactive zero-knowledge proof of knowledge of (dpk, (r, s)) such that: Bormann Expires 1 January 2027 [Page 14] Internet-Draft JWP-BBS June 2026 1. The 4 commitments at the indices in i open to the 128-bit limbs of dpk (in the layout of kb) under (G, H) (see Section 5). 2. (r, s) is a valid ECDSA P-256 signature on db_msg under dpk. [Editor's Note: TODO - select and describe concrete mechanism - expectation is that this will be described in another IETF draft] The Verifier accepts if the 4 indices in i are all committed in the core proof and the sub-proof verifies against the 4 commitments and the locally recomputed db_msg. 4.4.2. Range Proof Sub-Proof Algorithm identifier: sigma-range Inputs (beyond the base sub-proof fields): bounds l and u as JSON integers. The i field MUST be a single-element array [idx]. The sub-proof attests that m_idx, the message committed in the core proof at index idx, satisfies l <= m_idx < u. l < u, u - l >= 2, and u - l <= 2^64 MUST hold. The 2^64 ceiling accommodates NumericDate values (Section 4.1 of [RFC7519]). The lower bound rules out single-value ranges, for which the construction is degenerate. Implementations MUST parse l and u as bigints. A deployment profile MAY permit a larger width. The construction operates in BLS12-381 G1 against C_idx and follows the sigma-protocol range proof of Section 5.5 of [I-D.ietf-privacypass-arc-crypto]: * Let k and (base[0], ..., base[k-1]) be the outputs of ComputeBases(u - l) (Section 5.5 of [I-D.ietf-privacypass-arc-crypto]). The Holder writes m_idx - l as the sum over j in [0, k-1] of b[j] * base[j], with each b[j] constrained to {0, 1}. * For each j in [0, k-1], the Holder samples blinding scalars s[j] and s2[j] and forms the bit commitment D[j] = b[j] * G + s[j] * H over (G, H) of Section 5. The Holder then proves, in a single batched Schnorr step, knowledge of (b[j], s[j], s2[j]) such that D[j] = b[j] * G + s[j] * H and D[j] = b[j] * D[j] + s2[j] * H (the linearized bit constraint), producing per-bit Schnorr commitments T1[j] and T2[j] from fresh per-bit random scalars. * The challenge is c = hash_to_scalar(transcript, challenge_dst) with challenge_dst = api_id || "SIGMA_RANGE_CHAL_" and hash_to_scalar the base BBS primitive of Section 5. [Editor's Note: describe wire format of proof] Bormann Expires 1 January 2027 [Page 15] Internet-Draft JWP-BBS June 2026 4.4.3. Equality Proof Sub-Proof Algorithm identifier: schnorr-eq Inputs (beyond the base sub-proof fields): * i: a single-element array [idx]. * c_ext: a base64url-encoded BLS12-381 G1 point. The sub-proof attests that C_idx (from the core proof) and c_ext open to the same scalar under the generators (G, H) of Section 5. Cross- group equality is out of scope. The construction is a 3-DL Schnorr discrete-logarithm-equality (DLEQ) proof over BLS12-381 G1 with (G, H), with witness (m, s_1, s_2) such that: C_idx = m * G + s_1 * H c_ext = m * G + s_2 * H The Holder samples fresh random scalars (r_m, r_s1, r_s2) and computes Schnorr commitments T_1 = r_m * G + r_s1 * H and T_2 = r_m * G + r_s2 * H. The challenge is c = hash_to_scalar(transcript, challenge_dst) with challenge_dst = api_id || "SCHNORR_EQ_CHAL_" and hash_to_scalar the base BBS primitive of Section 5. [Editor's Note: describe wire format of proof] 4.5. Example Presentation Continuing the example of Section 2.4, a Verifier requests family_name and asks the Holder to prove exp is in the future without disclosing it. The Presentation Header: { "nonce": "f4Oa3wT0r8m2Vn1pQ7sKdA", "aud": "https://verifier.example.com" } The Holder marks index 1 (family_name) as DISCLOSE, index 13 (exp) as COMMIT, and the rest as HIDE. The core proof then carries a fresh Pedersen commitment to m_13. The Holder attaches a sigma-range sub- proof over index 13 proving now <= exp < 2^63 (with now = 1779926400): Bormann Expires 1 January 2027 [Page 16] Internet-Draft JWP-BBS June 2026 { "alg": "sigma-range", "input": { "i": [13], "l": 1779926400, "u": 9223372036854775808 }, "proof": "..." } The Compact Serialization concatenates with .: Presentation Header, Issuer Header, Presentation Payloads, Presentation Proof. The disclosed family_name at index 1 is the only populated payload and the other thirteen slots are empty: . . ~TXVzdGVybWFubg~~~~~~~~~~~~ . ~ The Verifier verifies the core proof, recovers C_13, and checks the sub-proof against it. It learns family_name and that the credential has not expired. 4.6. Reconstructed JSON Payload After verifying the core proof and any sub-proofs, the Verifier SHOULD convey to the application a JSON object reconstructed from the disclosed information, analogous to the Processed SD-JWT Payload of [RFC9901]: 1. Start from { "vct": }. 2. Walk claims. For each leaf at a disclosed index i, set its value from the corresponding Presentation Payload (per Section 2.5), except when the payload octets are byte-equal to the decoy octets for that leaf's scalar flag (see Section 2.10), in which case omit the leaf. Hidden and committed-but-not-disclosed leaves are omitted. 3. Preserve the object and array structure of claims for surviving leaves. Array entries that were omitted do not appear, so reconstructed array indices may differ from those in the claims annotations. Predicates established by sub-proofs are not represented as leaf values. The reconstruction procedure MUST NOT populate values for hidden or committed-but-not-disclosed leaves. For Section 4.5, the reconstructed payload is: Bormann Expires 1 January 2027 [Page 17] Internet-Draft JWP-BBS June 2026 { "vct": "https://credentials.example.com/identity_credential", "family_name": "Mustermann" } 5. Cipher Suite This profile fixes exactly one cipher suite, so that alg does not vary across a credential population and split its anonymity set (see Section 7.1). 5.1. Identifier JPA Algorithm JSON Label: BBS-MOD. Cipher suite identifier (also used as api_id for hash-to-scalar, generator derivation, and sub-proof domain separation): BBS-MOD_BLS12381G1_XMD:SHA-256_SSWU_RO_BLIND_H2G_HM2S_ The BBS-MOD_ prefix separates this profile from both the base BBS JPA (BBS of Section 9.1.2.4 of [I-D.ietf-jose-json-proof-algorithms]) and the base blind BBS Interface (BBS_BLS12381G1_XMD:SHA- 256_SSWU_RO_BLIND_H2G_HM2S_). This profile adds committed-message proof generation to that Interface. It also bypasses hash-to-scalar on a per-message basis under the scalar flag and attaches sub-proofs as described in Section 4.4. 5.2. Parameters * *Curve / group*: BLS12-381, G1 subgroup. * *Underlying BBS ciphersuite*: BLS12-381-SHA-256 (Section 7.2.2 of [I-D.irtf-cfrg-bbs-signatures]) with hash-to-curve SHA-256 SSWU random oracle [RFC9380]. * *Hash-to-scalar*: as in the underlying BBS ciphersuite, with domain separation derived from api_id. * *Core proof operations*: CoreProofGen / CoreProofVerify of [I-D.irtf-cfrg-bbs-blind-signatures] invoked directly (not via BlindProofGen), so implementations MUST apply the input validity checks of Section 7.1 of that document. * *Pedersen commitment generators*: (G, H) = (Y_1, Y_0) where (Y_0, Y_1) = BBS.create_generators(2, "COM_DIS_" || api_id). Every committed-index commitment has the form C_i = m_i * G + s_i * H with s_i sampled per presentation by CoreProofGen. * *Per-message hash-to-scalar bypass*: governed by each leaf's scalar flag (see Section 2.3). Bormann Expires 1 January 2027 [Page 18] Internet-Draft JWP-BBS June 2026 The base BBS KeyGen, Sign, and Verify operations defined by this document use the BBS ciphersuite identifier BBS- MOD_BLS12381G1_XMD:SHA-256_SSWU_RO_. The BBS draft's default api_id = ciphersuite_id || "H2G_HM2S_" is not used. All base-BBS operations are parameterized by the api_id defined above (carrying the BLIND_H2G_HM2S_ suffix). 6. Security Considerations 6.1. Random Number Generation All randomness used by this document MUST be generated using a cryptographically secure random number generator. Reuse or predictability of a blinding scalar or proof nonce can break unlinkability or soundness, or even leak the signing key. ECDSA implementations SHOULD use deterministic nonces per [RFC6979]. 6.2. Hash-to-Scalar Bypass [Editor's Note: TODO - Check what exactly the attack scenarios are / if there are some] 7. Privacy Considerations 7.1. Issuer Header Correlation The Issuer Header is sent in clear to the Verifier. Any variation in it across Holders of the same vct narrows the anonymity set. Implementations SHOULD make the Issuer Header byte-identical across the entire population of a vct, by: * Fixing the claims layout (including all optional attributes and maximum-length array slots) with a constant serialization. * Filling unused slots with decoys per Section 2.10. * Carrying per-credential metadata (issuance time, expiry, identifiers) as messages in the message vector 7.2. Cipher Suite and Algorithm Identifiers alg and kb likewise split the anonymity set when they vary across the population of a vct. Implementations SHOULD use a single alg and a single kb value (or omit kb entirely) across all credentials of a vct, and SHOULD NOT mix device-bound and non-device-bound credentials under the same vct. Bormann Expires 1 January 2027 [Page 19] Internet-Draft JWP-BBS June 2026 8. IANA Considerations This document requests the following registrations and registry creations. 8.1. JPA alg Value IANA is requested to register the following JSON Proof Algorithm in the "JSON Web Proof Algorithms" registry established by [I-D.ietf-jose-json-proof-algorithms]: * Algorithm Name: BBS-MOD using SHA-256 * Algorithm JSON Label: BBS-MOD * Algorithm CBOR Label: (to be assigned by IANA) * Algorithm Description: Blind BBS over BLS12-381 with CoreProofGen- based committed-message proofs, the per-message scalar flag, and the sub-proof attachment mechanism of Section 4.4. Cipher suite identifier BBS-MOD_BLS12381G1_XMD:SHA-256_SSWU_RO_BLIND_H2G_HM2S_. * Algorithm Usage Location(s): Issued, Presented * JWP Implementation Requirements: Optional * Change Controller: IETF * Specification Document(s): Section 5 of this document. * Algorithm Analysis Document(s): [LSZ25], [CT25] 8.2. Header Parameter Registrations IANA is requested to register the following Header Parameters in the "JSON Web Proof Header Parameters" registry established by [I-D.ietf-jose-json-web-proof]: * Header Parameter Name: claims * Header Parameter Description: Mapping from credential attribute names to their position in the BBS message vector and whether each is hashed to a scalar or supplied directly as a scalar. * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 2.3 of this document. * Header Parameter Name: kb * Header Parameter Description: Identifier for the device public-key type and its encoding layout in the BBS message vector. * Header Parameter Usage Location(s): Issued, Presented Bormann Expires 1 January 2027 [Page 20] Internet-Draft JWP-BBS June 2026 * Change Controller: IETF * Specification Document(s): Section 2.8 of this document. 8.3. Sub-Proof Algorithms Registry IANA is requested to create a new "Sub-Proof Algorithms" registry. Allocation policy: Specification Required ([RFC8126]). Designated experts SHOULD verify that each entry pins its underlying group, generators, transcript hash, and Fiat-Shamir domain separation, and that the sub-proof is bound to a commitment attested by the core proof per Section 4.4. Registry fields: Identifier (the alg value of a sub-proof object), Description, Reference, Change Controller. Initial entries: * Identifier: ecdsa-p256-db * Description: ECDSA P-256 device-binding sub-proof. * Reference: This document, Section 4.4.1. * Change Controller: IETF. * Identifier: sigma-range * Description: Sigma-protocol range proof over a committed scalar message. * Reference: This document, Section 4.4.2. * Change Controller: IETF. * Identifier: schnorr-eq * Description: Schnorr proof of equality between a committed message and an external commitment. * Reference: This document, Section 4.4.3. * Change Controller: IETF. 9. References 9.1. Normative References Bormann Expires 1 January 2027 [Page 21] Internet-Draft JWP-BBS June 2026 [FIPS186-5] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023, . [I-D.ietf-jose-json-proof-algorithms] Jones, M. B., Waite, D., and J. Miller, "JSON Proof Algorithms", Work in Progress, Internet-Draft, draft-ietf- jose-json-proof-algorithms-13, 2 March 2026, . [I-D.ietf-jose-json-web-proof] Waite, D., Jones, M. B., and J. Miller, "JSON Web Proof", Work in Progress, Internet-Draft, draft-ietf-jose-json- web-proof-13, 2 March 2026, . [I-D.ietf-oauth-sd-jwt-vc] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-16, 24 April 2026, . [I-D.ietf-privacypass-arc-crypto] Yun, C., Wood, C. A., and A. F. Faz-Hernandez, "Anonymous Rate-Limited Credentials Cryptography", Work in Progress, Internet-Draft, draft-ietf-privacypass-arc-crypto-01, 2 March 2026, . [I-D.irtf-cfrg-bbs-blind-signatures] Kalos, V. and G. M. Bernstein, "Blind BBS Signatures", Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs- blind-signatures-03, 26 June 2026, . [I-D.irtf-cfrg-bbs-signatures] Looker, T., Kalos, V., Whitehead, A., and M. Lodder, "The BBS Signature Scheme", Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs-signatures-10, 8 January 2026, . Bormann Expires 1 January 2027 [Page 22] Internet-Draft JWP-BBS June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, . 9.2. Informative References [CT25] Chairattana-Apirom, R. and S. Tessaro, "On the Concrete Security of BBS/BBS+ Signatures", 2025, . [LSZ25] Lehmann, A., Sidorenko, A., and A. Zacharakis, "Vision: A Modular Framework for Anonymous Credential Systems", IACR ePrint 2025/1981, 2025, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . Bormann Expires 1 January 2027 [Page 23] Internet-Draft JWP-BBS June 2026 [TS14] European Commission, EUDI Wallet Expert Group, "Specification for the implementation of Zero-Knowledge Proofs based on multi-message signatures in the EUDI Wallet (TS-14)", Work in Progress., EUDI TS-14, 2025, . Appendix A. Acknowledgments This document rests on the work captured in [TS14] by the EUDI Wallet expert group. The committed-message core proof builds on [I-D.irtf-cfrg-bbs-blind-signatures], and the modular committed- disclosure framework draws on [LSZ25]. Appendix B. Document History [[ pre Working Group Adoption: ]] -00 * Initial Version Author's Address Christian Bormann SPRIND GmbH Email: chris.bormann@gmx.de Bormann Expires 1 January 2027 [Page 24]