T2.1.1. Profile 2A: BBS+ Linked-Secret Proof

The holder possesses a secret s committed in the credentials of both DIDs. The ZK proof demonstrates equality of committed secrets across credentials without revealing s, following the AnonCreds link-secret model adapted for Universal Manifest. Evaluators MUST verify the BBS+ proof of equality against the issuer's BLS12-381 G2 public keys for both credentials; the proof inherently demonstrates that the presenter possesses the holder-committed secret in both credentials.

A Profile 2A bindingProof MUST contain:

• type — MUST be "ZkLinkedSecretProof".
• cryptosuite — MUST be "bbs-2023" per the W3C Data Integrity BBS Cryptosuites.
• proofPurpose — MUST be "authentication".
• proofValue — Base64url-encoded BBS+ derived proof bytes.
• publicInputs — An object containing commitmentA and commitmentB, the BBS+ commitments from each credential.

BBS+ signatures ([BBS+]) are the RECOMMENDED cryptographic suite for privacy-preserving Tier 2 operations: BBS+ derived proofs are unlinkable across presentations, and selective disclosure is native to the signature scheme.

T2.1.2. Profile 2B: HD Derivation Proof

Both DIDs are derived from a common master seed via hierarchical deterministic key derivation (BIP-32/SLIP-10). The ZK proof demonstrates that a master seed exists such that the two public keys are derivable at declared paths, without revealing the seed.

A Profile 2B bindingProof MUST contain:

• type — MUST be "ZkHdDerivationProof".
• proofSystem — The ZK proof system used (e.g., "groth16"). Evaluators MUST support Groth16 [Groth16]; MAY support PLONK or Bulletproofs.
• circuit — URI identifying the HD derivation circuit (e.g., "urn:uuid:circuit-hd-derivation-v1").
• proofValue — Base64url-encoded proof bytes.
• publicInputs — An object containing publicKeyA, publicKeyB, derivationPathA, and derivationPathB.

Groth16 proofs require a per-circuit trusted setup ceremony. The ceremony parameters MUST be publicly auditable. Evaluators MUST verify proofs against the published verification key.

T2.1.3. Verification Procedure

When an evaluator encounters an identity.crossDidBinding claim carrying a bindingProof, it MUST apply the following procedure (the declared requiredTrustTier governs what the verified result must satisfy, not whether the proof is verified):

1. Identify the proof type from bindingProof.type.
2. For ZkLinkedSecretProof: verify the BBS+ derived proof against the issuer's BLS12-381 G2 public keys referenced in the claim's credentials. Confirm that the proof demonstrates equality of the committed holder secret.
3. For ZkHdDerivationProof: resolve the circuit URI, retrieve the verification key, construct the public inputs from the declared public keys and derivation paths, and verify the ZK proof.
4. Record the result in the receipt. A verified proof elevates the claim to Tier 2. A proof that fails verification MUST cause the claim to be recorded as failed and treated at Tier 0, regardless of any accompanying attestations; evaluators MAY apply stricter local policy (for example, rejecting the manifest). Only an absent bindingProof falls back to attester-asserted Tier 1 evaluation.

(Worked example: Tier 2 cross-DID binding with linked-secret proof — see Cookbook.)

Preview — built on default: This makes Groth16 the mandatory-to-implement proof system for Profile 2B (smallest proofs, fastest verification), with PLONK permitted as an optional alternative for deployments that prefer a universal setup. Working-group input is requested on whether the trusted-setup cost of Groth16 justifies making PLONK the baseline instead. Flag to revise.

T2.2.1. Privacy Considerations for Track B

The privacy–binding tension is fundamental: stronger binding enables correlation, while stronger privacy prevents binding verification. The specification provides mechanisms for both and requires evaluators to define their trust tier based on their threat model. Evaluators MUST NOT require cross-DID binding unless their use case demands Sybil resistance or trust transitivity; subjects SHOULD use the minimum binding tier that satisfies their evaluators' requirements. BBS+ pseudonym scope: if pseudonymScope is reused across verifiers, cross-verifier correlation becomes possible; issuers SHOULD generate unique scope URIs per verifier relationship, and evaluators MUST NOT use a shared pseudonym scope for multiple independent verifier relationships (EXT-T1 §T1.6.1).

Preview: The dual-track model is built on the editors' default (SD-JWT baseline; BBS+ for privacy-critical and Tier 2). Working-group input is requested on whether Track B should be mandatory for any class of spatial-computing deployment.

T2.3.1. Candidate Algorithms

The following NIST-standardized post-quantum signature algorithms are candidates:

• ML-DSA (CRYSTALS-Dilithium) — NIST FIPS 204. Lattice-based, moderate signature size (~2.4 KB for ML-DSA-65), fast verification. The leading candidate for general-purpose post-quantum signatures.
• SLH-DSA (SPHINCS+) — NIST FIPS 205. Hash-based, larger signatures (~8–30 KB), no lattice assumptions (conservative choice). Suitable as a fallback if lattice-based schemes are broken.
• FN-DSA (FALCON) — NIST (pending standardization). Lattice-based, compact signatures (~666 bytes for FALCON-512), more complex implementation. Suitable for constrained devices where signature size is critical.

T2.3.2. Profile Naming

The post-quantum profile follows the signature-profile naming convention of Base §1.6. The recommended baseline profile is Signature Profile B: JCS + ML-DSA-65.

T2.3.3. Dual-Signature Migration Path

The transition from Ed25519 to post-quantum signatures uses a dual-signature period. During this period, manifests carry both an Ed25519 signature (in the existing signature field) and a post-quantum signature (in a new postQuantumSignature field).

• Evaluators that support the post-quantum profile MUST verify both signatures.
• Evaluators that do not yet support the post-quantum profile MUST verify only the Ed25519 signature and MUST ignore the postQuantumSignature field.
• The dual-signature period begins when the post-quantum profile is published and ends when the working group declares Ed25519-only manifests non-conformant at a major-version boundary.

The postQuantumSignature field follows the same schema as signature (Base §1.6) with the algorithm field set to the post-quantum algorithm identifier (e.g., "ML-DSA-65"). Both proofs are computed over the same signing input: the canonical bytes of Base §1.6.3 with the signature, postQuantumSignature, and (if present) presentationProof properties removed, so that neither signature's bytes feed the other's input.

(Worked example: dual-signature manifest — see Cookbook.)

Notes (working-group): Whether the dual-signature mechanism should use a separate top-level field or an array of signature objects is open (separate field is simpler for backward compatibility; an array is more extensible). ML-DSA-65 signatures (~2.4 KB) are significantly larger than Ed25519 (64 bytes); the working group is assessing whether this size increase matters for constrained-device deployments.