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. The two credentials are carried in (or resolvable from) the claim's claimProof entries (Base §6.4.3); a Profile-2A claim without resolvable credentials for both boundDids fails verification. 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. Confirm the claim's boundDids cardinality is exactly 2 (T2.1), and identify the proof type from bindingProof.type.
2. For ZkLinkedSecretProof (Profile 2A): verify the BBS+ derived proof against the issuer's BLS12-381 G2 public keys referenced in the claim's credentials, and confirm that the proof demonstrates equality of the committed holder secret. Then bind the proof to the claimed DIDs: confirm that each credential against which the proof verifies resolves to a distinct member of boundDids as its credential subject — together, the two credential subjects MUST equal the boundDids pair. A proof whose credential subjects do not match boundDids demonstrates only that the presenter controls some pair of credentials, not the claimed binding.
3. For ZkHdDerivationProof (Profile 2B): 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. Then bind the public inputs to the claimed DIDs: resolve each bound DID's DID document and confirm that publicKeyA is a verification method of boundDids[0] and publicKeyB is a verification method of boundDids[1], respectively (listed in, or referenced from a verification relationship of, that DID's DID document). A bound DID whose DID document cannot be resolved fails this check. The ZK proof alone demonstrates only that the two declared keys derive from one master seed; the DID-document check is what ties those keys to the DIDs the claim asserts are bound — without it, a holder could present a valid proof over two keys it controls while boundDids names arbitrary DIDs.
4. Record the result in the receipt. A proof that both verifies and binds elevates the claim to Tier 2. Any failure or mismatch in steps 1–3 — a cardinality violation, a failing proof, a credential subject that is not a distinct member of boundDids, or a declared public key that is not a verification method of its respective bound DID — 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.2.2. Claiming Tier-2 Privacy-Preserving Binding PREVIEW

Tier-2 privacy-preserving binding — the property Track B is REQUIRED for (T2.0, T2.2) — is a claimable conformance label, not a new mechanism. Its candidate registered-profile identifier is um:profile:trust:tier2-privacy-preserving-binding (a trust-category profile per EXT-OPT §O6; the identifier is provisional until registration). Following the thin conformance-profile-label precedent of EXT-T1 §T1.3.3, the label names a bundle of existing requirements and defines no new ceremony, cryptography, or member. A deployment conforms to the label when, together:

1. cross-DID binding is verified at Tier 2 via a T2.1 proof profile, including the boundDids binding steps of T2.1.3;
2. credential-level selective disclosure uses Track B (BBS+ derived proofs, T2.2) for the credentials involved — Track A alone MUST NOT be the basis of this claim; and
3. the pseudonym-scope discipline of T2.2.1 / EXT-T1 §T1.6.1 is applied.

The label is claimed in the deployment's conformance claim (EXT-OPT §O11.1, item 2 — implemented modules and claimed PREVIEW features); it adds no manifest wire member.

T2.3.1. Candidate Algorithms

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

• ML-DSA (CRYSTALS-Dilithium) — NIST FIPS 204 [FIPS204]. 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 [FIPS205]. 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. Profile B shares Profile A's canonicalization: in a postQuantumSignature object following Profile B, canonicalization MUST be "JCS-RFC8785" and algorithm MUST be "ML-DSA-65"; the algorithm + canonicalization pair identifies the profile, exactly as Base §1.6.5 requires for signature, and an evaluator that processes postQuantumSignature at all MUST apply the same unsupported-pair rejection discipline to it.

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, and MUST reject the manifest if either verification fails. Dual verification is conjunctive: one valid signature never compensates for the other's failure. (Accepting on one-of-two would let a forgery under a broken algorithm ride on the other signature's validity — defeating the purpose of carrying both during exactly the period this mechanism exists to protect.)
• 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.