]> SPRIND GmbH

chris.bormann@gmx.de

Security TODO Working Group zero-knowledge proofs multi-message signatures BBS JWP 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 . Discussion of this document takes place on the JSON Web Proofs Working Group mailing list (jose@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The BBS signature scheme is a multi-message signature (MMS) scheme where the signer produces a single signature over a vector of messages m0 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 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 as the serialization/container format for both issuance and presentation, and defines a JSON Proof Algorithm profile based on Blind BBS Signatures.
• Builds its core proof on CoreProofGen of , 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.

This modular architecture builds on prior work and , and the credential type and metadata model are reused from SD-JWT VC .

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 when, and only when, they appear in all capitals, as shown here.

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.

Terms and Definitions This document uses the Issuer-Holder-Verifier model and terminology of . 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.

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

Issued Credential A credential is issued in the Issued Form (see Section 6.1 of ) consisting of:

• An Issuer Header (Section 6.1.1 of ) with the contents specified in .
• n Issuer Payloads (Section 6.1.2 of ), where n is the length of the BBS message vector (see ). The Issuer Payload at position i is the octet string from which the scalar message m_i is derived per .
• An Issuer Proof (Section 6.1.3 of ) 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 ). CBOR Serialization is (currently) out of scope for this document.

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 ). This profile defines the JPA value BBS-MOD (see ).

vct (string, REQUIRED):

The credential type identifier as defined in Section 3.2.2.1 of .

claims (JSON object, REQUIRED):

The mapping from claim names to message-vector positions and per-message encoding - see for more details.

kb (string, OPTIONAL):

The device-binding identifier - see . 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 for more details. The JWP iek, hpk, and hpa Header Parameters (Sections 5.2.5–5.2.7 of ) MUST NOT appear in the Issuer Header.

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 ).
  • 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 ).

Let n be the length of the message vector, and N the number of payload slots reserved for the device-key encoding (see ), 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 ) but not populated by a given credential MUST carry the decoy value defined in .

Example: Issuance Starting from an SD-JWT VC-style claim set : 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 ) to allow range sub-proofs over them. The resulting Issuer Header is: Indices 0–11 use hash-to-scalar and indices 12–13 carry NumericDate integers () directly as scalars. A presentation can then mark iat/exp as COMMIT (see ) and attach sigma-range sub-proofs (see ) 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 ).

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 . This is the per-message derivation of BBS.messages_to_scalars (Section 4.1.2 of ).

For an annotation [i, true] with leaf value v:

1. o is the canonical decimal octet encoding of v (see ), carried as Issuer Payload i.
2. m_i is the integer denoted by o, interpreted as an element of the BBS scalar field.

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

Temporal Claims The JWT temporal claims exp, nbf, and iat (Section 4.1 of ), 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.

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 ) 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 ). The Issuer MUST make sure that (x, y) is a valid non-identity P-256 point before computing the message vector.

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 ). For optional claims, claims MUST contain the index entry regardless of whether the attribute is present in a given credential.

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: with hash_to_scalar and map_dst as defined in . 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 ).

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

Issuance

Issuer Key Generation The Issuer key pair is a BBS key pair (Section 3.4 of ) using the cipher suite of .

Credential Issuance To issue a credential, the issuer performs the following steps:

1. Construct the Issuer Header per and .
2. Derive the message vector (m_0, ..., m_(n-1)) per and , filling decoys per .
3. Compute the blind BBS signature over header_octets and the message vector.
4. Assemble and serialize the Issued Form per .

A non-normative example of the Compact Serialization: . ~~ ... ~ . ]]> Each <m_i> is the base64url-encoded Issuer Payload for index i (e.g., m_1 is "Mustermann", m_13 is 1786000000).

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.

Presentation

Presented Form A presentation is a Presented Form (Section 6.2 of ) consisting of:

1. A Presentation Header per .
2. The Issuer Header from issuance, byte-identical to the issued form.
3. n Presentation Payloads (Section 6.2.2 of ): disclosed positions carry the corresponding Issuer Payload and undisclosed positions are omitted (see Section 7.1 of ).
4. A Presentation Proof (Section 6.2.4 of ) consisting of one or more octet strings. The first octet string is the encoded core proof (see ). Subsequent octet strings, if any, are UTF-8 JSON-serialized sub-proof objects (see ) and MAY appear in any order. The Compact Serialization base64url-encodes each octet string.

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

aud (string, REQUIRED):

The Audience Header Parameter (Section 5.2.9 of ).

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 ). Verifiers MUST use those octets as received.

Core Proof The Holder builds a per-message disclosure map assigning each index in [N, n-1] (where N is as in ) 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 ) 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 with:

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

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

Sub-Proofs A sub-proof is a JSON object carried as an additional octet string of the Presentation Proof (see ) with the following members:

alg (string, REQUIRED):

The sub-proof algorithm identifier from the Sub-Proof Algorithms registry (see ).

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 encoding of the sub-proof bytes specified by alg.

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 ). Sub-proof transcripts use the BBS encoding primitives of Section 4.2.4.1 of : 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 and 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.]

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

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 ). The device-signed message is not transmitted, it is recomputed as: 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:

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

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 ). 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 :

• Let k and (base[0], ..., base[k-1]) be the outputs of ComputeBases(u - l) (Section 5.5 of ). 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 . 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 .

[Editor's Note: describe wire format of proof]

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 . 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: 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 . [Editor's Note: describe wire format of proof]

Example Presentation Continuing the example of , a Verifier requests family_name and asks the Holder to prove exp is in the future without disclosing it. The Presentation Header: 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): 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.

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 :

1. Start from { "vct": <vct from Issuer Header> }.
2. Walk claims. For each leaf at a disclosed index i, set its value from the corresponding Presentation Payload (per ), except when the payload octets are byte-equal to the decoy octets for that leaf's scalar flag (see ), 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 , the reconstructed payload is:

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

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): The BBS-MOD_ prefix separates this profile from both the base BBS JPA (BBS of Section 9.1.2.4 of ) 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 .

Parameters

• Curve / group: BLS12-381, G1 subgroup.
• Underlying BBS ciphersuite: BLS12-381-SHA-256 (Section 7.2.2 of ) with hash-to-curve SHA-256 SSWU random oracle .
• Hash-to-scalar: as in the underlying BBS ciphersuite, with domain separation derived from api_id.
• Core proof operations: CoreProofGen / CoreProofVerify of 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 ).

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

Security Considerations

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 .

Hash-to-Scalar Bypass [Editor's Note: TODO - Check what exactly the attack scenarios are / if there are some]

Privacy Considerations

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 .
• Carrying per-credential metadata (issuance time, expiry, identifiers) as messages in the message vector

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.

IANA Considerations This document requests the following registrations and registry creations.

JPA alg Value IANA is requested to register the following JSON Proof Algorithm in the "JSON Web Proof Algorithms" registry established by :

• 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 . 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): of this document.
• Algorithm Analysis Document(s): ,

Header Parameter Registrations IANA is requested to register the following Header Parameters in the "JSON Web Proof Header Parameters" registry established by :

• 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): 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
• Change Controller: IETF
• Specification Document(s): of this document.

Sub-Proof Algorithms Registry IANA is requested to create a new "Sub-Proof Algorithms" registry. Allocation policy: Specification Required (). 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 . 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, .
• Change Controller: IETF.
• Identifier: sigma-range
• Description: Sigma-protocol range proof over a committed scalar message.
• Reference: This document, .
• Change Controller: IETF.
• Identifier: schnorr-eq
• Description: Schnorr proof of equality between a committed message and an external commitment.
• Reference: This document, .
• Change Controller: IETF.

References Normative References National Institute of Standards and Technology Informative References European Commission, EUDI Wallet Expert Group Work in Progress.

Acknowledgments This document rests on the work captured in by the EUDI Wallet expert group. The committed-message core proof builds on , and the modular committed-disclosure framework draws on .

Document History [[ pre Working Group Adoption: ]] -00

• Initial Version