BBS and Modular Sub-proofs with JSON Web Proofs

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

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]:¶

{
  "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:¶

{
  "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:¶

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

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

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

<base64url(Issuer Header)>
.
<m_0>~<m_1>~ ... ~<m_13>
.
<base64url(blind BBS signature)>

Each <m_i> 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.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.¶
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:¶

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

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

db_msg = "JWP-BBS-DB-CHAL" || presentation_header_octets

C_idx = m * G + s_1 * H
c_ext = m * G + s_2 * H

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

{
  "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:¶

<base64url(Presentation Header)>
.
<base64url(Issuer Header)>
.
~TXVzdGVybWFubg~~~~~~~~~~~~
.
<core proof>~<sigma-range sub-proof>

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": <vct from Issuer Header> }.¶
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:¶

{
  "vct": "https://credentials.example.com/identity_credential",
  "family_name": "Mustermann"
}

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

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

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¶

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