T3.0. Scope and Relationship to the Base

The Base defines Tier 3 — Multi-party ceremony (Base §6.4.2) as the highest assurance level, in which multiple keyholders (potentially different people in different locations) co-sign, analogous to multi-sig wallets, and reserves the ceremonyProof field on identity.crossDidBinding claims (Base §6.4.4). This profile specifies the ceremony model, the ceremonyProof schema, the signer-role taxonomy, threshold-protocol selection, and the verification procedure.

Because trust tiers are strictly additive, a Tier-3 deployment MUST also implement EXT-T1 (Tier-1 binding) and, where it relies on Tier-2 cryptographic binding as the per-attester proof, EXT-T2.

T3.1. Ceremony Model

A Tier 3 ceremony is a protocol by which multiple independent attesters jointly verify and co-sign a cross-DID binding. The ceremony produces a single aggregate proof represented in a ceremonyProof object on the identity.crossDidBinding claim.

A ceremonyProof MUST contain:

• type — MUST be "ThresholdAttestationProof".
• threshold — A string in the format "M-of-N" (e.g., "3-of-5") declaring the quorum requirement.
• attesters — An array of DID strings identifying the ceremony participants who contributed to the aggregate proof. The array MUST contain at least M entries.
• ceremonyId — A globally unique URI identifying this ceremony instance.
• aggregateProof — The aggregate proof value. The encoding depends on the threshold protocol used.

T3.2. Signer-Role Taxonomy

Ceremony participants MAY declare roles. The following roles are recognized:

• "subject" — The manifest subject, asserting their own identity.
• "witness" — An independent party who attests to the subject's identity through direct verification.
• "custodian" — A keyholder who holds a key share on behalf of an organization.
• "auditor" — A party who reviews the ceremony transcript and co-signs as a quality check.

Profile documents MAY define role constraints (e.g., "at least 1 witness and 1 custodian"). When role constraints are declared, evaluators MUST verify that the attester list satisfies them.

T3.3. Threshold Protocol Selection

v0.4 defines the ceremony slot (the ceremonyProof schema) and proof format. The specific threshold protocol used to produce the aggregate proof is deferred to profile documents. Implementations MAY use any threshold protocol that produces a verifiable aggregate proof.

Non-normative guidance: FROST (Flexible Round-Optimized Schnorr Threshold signatures, [RFC9591]) is a candidate threshold protocol for Ed25519-based ceremonies; it produces standard Schnorr/Ed25519 signatures from a threshold of signers, and verifiers see a normal signature. Threshold BBS+ (Doerner et al. 2023) is a candidate for anonymous credential issuance ceremonies. Neither protocol is normatively required; profile documents define the binding.

T3.4. Verification Procedure

When an evaluator encounters an identity.crossDidBinding claim with requiredTrustTier: 3 and a ceremonyProof, the evaluator MUST:

1. Parse the threshold string to extract M and N.
2. Verify that the attesters array contains at least M entries.
3. If role constraints are declared in the profile, verify that the attester list satisfies them.
4. Verify the aggregateProof against the declared attesters using the threshold protocol specified by the profile.
5. For each attester DID, confirm the attester is on the evaluator's configurable trust list (per Base §6.4.4).
6. Record the result. A verified ceremony elevates the claim to Tier 3. A ceremonyProof that fails verification MUST cause the claim to be recorded as failed and treated at Tier 0, regardless of any accompanying attestations; only an absent ceremonyProof falls back to lower-tier evaluation of whatever binding material is present.

Evaluators that do not implement any Tier 3 threshold protocol MUST record the claim as "trustTierUnsupported" per Base §6.4.5.

(Worked example: Tier 3 ceremony proof — see Cookbook.)

Note (working-group): Whether the ceremony model should support asynchronous signing (signers sign at different times) or require synchronous co-presence is open. Asynchronous ceremonies are more practical for geographically distributed keyholders. Feedback is requested.

References

• [RFC9591] FROST: Flexible Round-Optimized Schnorr Threshold Signatures.
• [Threshold-BBS] Doerner et al. (2023), Threshold BBS+ Signatures.

Companion to the Base specification. For the lower tiers this builds on, see EXT-T1 and EXT-T2.