T1.1.1. Per-Mode Verification Procedure

For each mode, the evaluator performs the following verification during Stage-2 sub-step 2a (T1.4):

sd-jwt-kb.

1. Locate the SD-JWT and its Key Binding JWT (KB-JWT) in the claim's claimProof.
2. Confirm the credential's cnf JWK thumbprint ([RFC7638]) equals the declared cnfThumbprint.
3. Validate the KB-JWT signature with the confirmed holder key.
4. Confirm the KB-JWT aud equals the presentation audience and its nonce equals the presentation challenge (T1.2), and that its sd_hash covers the disclosed credential. When the same KB-JWT also serves as the manifest's presentationProof, its payload additionally carries the manifest-hash binding (um_manifest_hash — T1.2).
5. On any failure, record holderBindingStatus: "failed" and cap the claim at Tier 0.

bbs-holder-commitment. The binding carries the REQUIRED fields commitment (the issuer's commitment to the holder secret) and proofValue (the holder's zero-knowledge proof of possession), and the OPTIONAL pseudonymScope ([VC-DI-BBS]).

1. Verify the BBS+ derived proofValue demonstrates possession of the secret committed in commitment, against the issuer's BLS12-381 public key.
2. If pseudonymScope is present, confirm the pseudonym is bound to that scope (and not reused across verifiers — T1.6.1).
3. On failure, record holderBindingStatus: "failed" and cap the claim at Tier 0.

reciprocal-control. Confirm subjectProof and boundDidProof are each valid signatures over the manifest @id by the manifest subject key and the boundDid key respectively; on failure record holderBindingStatus: "failed". (See the limitation in T1.6.3.)

Verifying an sd-jwt-kb binding presupposes an interactive presentation: step 4 compares the KB-JWT aud and nonce against the audience and challenge of the presentation (T1.2). In non-interactive contexts (offline or cached presentation), holder binding at Tier 1 or above is carried by the bbs-holder-commitment or reciprocal-control modes, which verify without a verifier-issued challenge.

The receipt field holderBindingStatus records the outcome as one of "verified", "failed", "unsupported-mode", or "absent" (Base §3.3.1.1); "absent" indicates the claim carried no holderBinding.

T1.3.1. Per-Facet Liveness Floor (requiredLiveness) PREVIEW

A facet MAY declare a requiredLiveness floor (the OPTIONAL facet member named in Base §6.6). Its value is an object, because a liveness floor is a freshness class plus a boolean — a compound, unlike the closed integer requiredTrustTier:

• minFreshness — REQUIRED; one of "live", "recent", "stale", ordered live > recent > stale. "unknown" is not a valid floor value (a floor of "unknown" would be vacuous).
• userVerified — OPTIONAL boolean; default false. When true, the floor additionally requires the attestation's userVerified to be true.

The floor comparison order is live > recent > stale > unknown. A facet carrying requiredLiveness MUST NOT be processed unless a validated livenessAttestation yields a freshnessClass at least as fresh as minFreshness, and — when userVerified: true is required — the attestation's userVerified is true. Enforcement is sequenced in the Consent stage (Base §3.1.4) and recorded in the receipt.

The floor is fail-closed:

• userVerified absent ≡ false. For a floor requiring userVerified: true, an attestation lacking userVerified: true (including absent) MUST fail the floor.
• Proof validation before freshness. An attestation whose proofValue does not validate under its proofType MUST be treated as "unknown" for floor purposes regardless of attestedAt; the floor check is sequenced strictly after proof validation, so a forged-but-fresh-looking attestation cannot bypass the floor.
• Absent or expired root attestation ⇒ no floor satisfied. If the root livenessAttestation is absent, or evaluates to freshnessClass: "unknown" because it is past its validUntil, then no requiredLiveness floor is satisfied — including a minFreshness: "stale" floor — and the facet is withheld. Because unknown is ordered lowest, no floor value can be met by an unknown root attestation.

A requiredLiveness floor is orthogonal to requiredTrustTier: it can only raise the unlock bar for its facet and never lowers any trust-tier floor.

T1.3.2. Authenticator Provenance PREVIEW

The userVerified flag proves a user-verification gesture occurred; it does not prove the provenance of the authenticator (a synced/exportable credential and a device-bound/non-exportable credential can both set userVerified: true), nor which human acted (subject-binding is holder binding, not this flag). The bare userVerified flag MUST NOT be relied on as evidence of hardware provenance. A deployment requiring a device-bound authenticator MUST express that requirement through deviceAttestation (EXT-OPT §O9.2 — the actual hardware-provenance structure), not through the liveness proofType (which names the method only); evaluators SHOULD additionally consult WebAuthn backup-eligibility / backup-state (BE/BS) flags where available. The receipt echoes whichever provenance signal the floor actually relied on: a device-bound requirement enforced via deviceAttestation is recorded as such, and the existing livenessStatus echo covers the liveness side.

T1.3.3. Locked-Tier Portable-Unlock Profile (um:profile:trust:locked-tier-portable-unlock) PREVIEW

This subsection registers a thin conformance-profile label, um:profile:trust:locked-tier-portable-unlock (a trust-category profile per the registration mechanism — EXT-OPT §O6). The label names a bundle of existing EXT-T1 requirements at locked-tier floors; it does not define any new ceremony or cryptographic mechanism. A facet (or the consent gating it) that conforms to this profile applies, together:

• the existing per-facet liveness floor requiredLiveness: {minFreshness: "live", userVerified: true} (§T1.3.1) as the user-verification floor — no new field;
• for the highest-assurance (device-bound) rung, the existing deviceAttestation structure (EXT-OPT §O9.2) plus WebAuthn backup-eligibility/backup-state (BE/BS) flags (§T1.3.2) — already the prescribed route for a device-bound requirement, no new field;
• the new per-facet assurance-class floor requiredAssuranceClass (defined below);
• the unlock-window session policy (EXT-OPT §O4.5) when the locked facet is opened in a time-boxed window; and
• the receipt assurance echo and the below-floor refusal status assuranceInsufficient (Base §3.3.1, Base §3.3.1.1).

The label is colon-namespaced (um:profile:trust:…), consistent with the um:profile:/um:reason: registries; it is not the dot-form used for agent-delegation and consent scope operation tokens.

The requiredAssuranceClass floor. A facet MAY declare an OPTIONAL requiredAssuranceClass member — a closed, UM-neutral, ordered enum naming the minimum authenticator assurance class the unlock gesture's provenance MUST reach:

• "software" — a software-held key / passphrase-derived key (the lowest rung; the default);
• "hardware-uv" — a hardware-backed authenticator performing user verification (e.g. a platform authenticator with a hardware-protected key);
• "hardware-bound" — a device-bound, non-exportable hardware authenticator (the highest rung; the device-bound provenance of §T1.3.2).

The ordering is software < hardware-uv < hardware-bound. When absent, the floor defaults to "software" (the lowest value, so an absent floor never raises the bar). requiredAssuranceClass is modeled in spirit on requiredTrustTier (Base §6.4.5): as with requiredTrustTier, the floor can only raise the bar (it never lowers the effective assurance requirement; requiredAssuranceClass is a facet-level member — this draft defines no manifest-level assurance floor), and it is fail-closed — if the asserted or achieved assurance class is below the facet's floor, the evaluator MUST NOT downgrade and MUST withhold the facet (content never released), recording the facet status assuranceInsufficient (Base §3.3.1), exactly parallel to how an unsupported requiredTrustTier records trustTierUnsupported.

Evidence→class determination. The class the unlock gesture achieved is determined by the evaluator, from evidence it has itself verified — never from an unverified assertion — under the following rule, evaluated top-down with the first match applying:

• hardware-bound — a verified deviceAttestation (EXT-OPT §O9.2) on the presented manifest whose attestation evidence shows device-bound, non-exportable provenance for the authenticator that performed the gesture (the §T1.3.2 route; WebAuthn backup-eligibility/backup-state flags, where available, corroborate non-exportability);
• hardware-uv — a validated livenessAttestation with userVerified: true whose proofType mechanics attest hardware-backed user verification (e.g. webauthn-uv performed by a platform authenticator), without verified device-bound provenance;
• software — every other case, including absent, unverifiable, or software-only evidence. Unverifiable evidence never raises the class (fail closed; the default rung is also the floor's default value).

The assuranceStatus.assertedClass receipt echo (Base §3.3.1.1) records the class the evaluator determined under this rule — it is evaluator-asserted, not a holder self-declaration; a holder-supplied class assertion, where a profile defines one, is a hint and MUST NOT raise the determined class. A deployment MAY substitute a stricter determination rule by local policy but MUST NOT weaken this one (for example, by treating software-only evidence as hardware-uv).

requiredAssuranceClass is orthogonal both to requiredTrustTier (trust tiers grade claim-verification / Sybil-resistance; the assurance class grades unlock-gesture strength — no formal mapping is asserted between the two axes) and to requiredLiveness (which it composes beside: the liveness floor grades freshness of presence, the assurance class grades provenance strength of the authenticator; a locked facet typically carries both). Because the floor is a property of the facet / consent, not of the unlock window or any spend ledger, a future single-use consent on a locked facet can require both a single-use spend constraint and this assurance floor without either field touching the other.

The following table maps each enum value to comparable assurance levels in external frameworks — NIST SP 800-63B-4 [NIST-800-63B], FIDO authenticator certification [FIDO-CERT], and eIDAS 2.0 [eIDAS2]. This mapping is INFORMATIVE only; the enum is the normative artifact, and UM asserts no conformance claim against NIST, FIDO, or eIDAS levels.

Schema note: invalid-enum or wrong-type requiredAssuranceClass fixtures are schema-detectable by the v0.4 facet shape validator, matching the precedent set by requiredLiveness (§T1.3.1). The evaluator still owns cross-field and runtime assurance-floor checks, including below-floor unlock attempts.

T1.5.1. claimProof Verification Procedure

When claiming Tier 1 assurance or higher, the evaluator MUST perform the verification steps below; at Tier 0 these checks are OPTIONAL.

• When claimProof is present as an embedded object, the evaluator MUST verify the VP proof chain: (a) the VC signature validates to the stated issuer, (b) the VP signature validates to the holder, (c) the holder DID matches the manifest subject.
• When present as a URI string, the evaluator MAY fetch the VP for verification when network access is available. Evaluators that cannot resolve the URI SHOULD record the claim as "unverified" with a reason such as um:reason:trust:claimproof-unresolved, rather than "verified".
• When claimProof is an array, each entry is independently verified; the claim is backed by the conjunction of all valid proofs.

VPs used as claimProof SHOULD include domain (audience binding) and challenge (nonce) parameters to prevent cross-manifest replay. Evaluators MUST enforce size limits of at most 50 KB per embedded VP and at most 500 KB total VP payload across all claims in one manifest, and MUST document any stricter limit in their conformance claim.

T1.5.2. Seven-Step Verification Chain

For each claim requiring Tier 1 or higher trust, the evaluator MUST execute the following seven-step procedure:

1. Verify outer manifest signature per Base §1.6. If the signature is invalid, the entire manifest is rejected.
2. Confirm manifest signing key authorization. Resolve the manifest subject DID document. Confirm that the signing key (referenced via signature.keyRef) appears in the subject's DID document under the authentication or assertionMethod verification relationship, per [DID-CORE] §5.3. If the manifest signing key is not authorized for the subject, the evaluator MUST record this as a verification failure.
3. Resolve the claim issuer DID. For each claim carrying claimProof, resolve the claims[].issuer DID document per W3C DID Resolution.
4. Verify the claim proof chain. If claimProof is present:
   1. Identify the proof type. If proofType is absent, infer from the proof structure.
   2. Verify the proof material per the declared proof type, following the VP proof-chain verification in T1.5.1.
   3. If verificationMethod is present, resolve the URI to the issuer's DID document. Confirm the key appears under the assertionMethod verification relationship. This is the key-authorization step: it proves the signing key was authorized by the stated issuer DID to issue credentials. (See [DID-CORE] §5.3 and [VC-DATA-MODEL] §4.12, Securing Mechanisms.)
   4. If statusRef is present on the proof entry, check revocation status per the statusRef resolution schema (EXT-OPT).
   5. If claimProof is an array, each entry is independently verified; the claim is backed by the conjunction of all valid proofs.
5. Verify attester key authorization (for attester-asserted identity.crossDidBinding claims; skipped when the binding carries only a cryptographic bindingProof or ceremonyProof, whose verification is defined in EXT-T2 and EXT-T3). Resolve the attester DID document. Confirm the attester's signing key appears under the assertionMethod verification relationship. Confirm the attester is on the evaluator's configurable trust list per Base §6.4.4.
6. Confirm key revocation status. For all signing keys encountered in steps 1–5 (manifest signer, claim issuer, attester), confirm that no key relied upon has been revoked, to the extent revocation information is available. Key revocation is determined per key source: for DID-based keys, the verification-method state in the key's DID document; for keys carried by a credential, the proof entry's own statusRef. This is distinct from the manifest-instance status resolved via signature.statusRef. Inner key revocation (claim-issuer and attester keys) SHOULD be checked when revocation information is available.
7. Compose per-claim outcomes. Aggregate the verification outcomes into the manifest's trust decision per Base §6.4.5 (requiredTrustTier floors) and emit the receipt per Base §3.3.

T1.5.3. Key Purpose Requirements

For each step that names a verification relationship, the evaluator MUST confirm the signing key appears under the matching W3C DID Core verification relationship:

• Manifest signature: authentication or assertionMethod on the manifest subject's DID document.
• VC issuance (claimProof embedded VP): assertionMethod on the VC issuer's DID document.
• Cross-DID binding attestation: assertionMethod on the attester's DID document.
• Agent delegation signing: capabilityDelegation on the delegator's DID document (Base §6.5).

T1.5.4. Trust Policy vs. Cryptographic Verification

The verification chain separates two concerns that MUST NOT be conflated:

• Cryptographic verification (steps 1–2, 4–6): mathematical proof that signatures are valid and keys are authorized. Deterministic.
• Trust policy (step 5 trust list, step 7 composition): which DIDs and attesters the evaluator trusts. Local configuration. The specification MUST NOT mandate a centralized trust registry; each evaluator defines its own trust policy.

Non-normative note: OMATrust's Key Binding attestation type operationalizes the key-authorization pattern for the EVM ecosystem. UM cites W3C DID Core and VCDM 2.0 as the normative sources for the verification-relationship model.

T1.6.1. BBS+ Pseudonym Scope

If pseudonymScope is reused across verifiers, cross-verifier correlation becomes possible. Issuers SHOULD generate unique scope URIs per verifier relationship. Evaluators MUST NOT use a shared pseudonym scope for multiple independent verifier relationships.

T1.6.2. ZK Proof System Trusted Setup

Tier 2 profiles using Groth16 require a trusted setup ceremony (EXT-T2). The ceremony parameters MUST be publicly auditable. Verifiers MUST verify proofs against the published verification key, not against a key provided by the prover.

T1.6.3. Reciprocal Control Limitations

Reciprocal control (two DIDs signing the same challenge) proves the same entity or cooperating entities control both keys. It does not prove they are the same natural person. For sameSubject assurance, combine reciprocal control with issuer-attested binding (Tier 1) or linked-secret proof (Tier 2 — EXT-T2).

T1.6.4. Backwards Compatibility (v0.3 manifests)

v0.4 evaluators encountering a v0.3 manifest (no holderBinding, no presentationProof, no livenessAttestation) MUST:

1. Parse and process the manifest through the six-stage evaluation sequence.
2. Record holderBindingStatus: "absent" in the receipt.
3. Record presentationProofStatus: "absent" in the receipt.
4. Record livenessStatus.freshnessClass: "unknown" in the receipt.
5. Cap the effective trust tier at Tier 0 regardless of requiredTrustTier declarations.

A v0.3 manifest that declares no manifest-level requiredTrustTier (or declares Tier 0) is accepted but flagged as "unbound" at Tier 0; evaluators decide their own policy for unbound manifests. Where a v0.3 manifest declares a manifest-level requiredTrustTier that cannot be satisfied because binding material is absent, Base §6.4.5 governs the outcome: accepted-partial if other items can still be processed, or rejected when the unsupported tier applies at the manifest level (or no processable items remain — Base §3.1.5). There is no display-only outcome branch; whether an application still renders anything after a rejected evaluation is an application-layer choice that does not change the receipt outcome. Capping the effective trust tier at Tier 0 (step 5) does not by itself reject the manifest; the declared floor does.

v0.4 evaluators SHOULD emit an um:reason:trust:unbound-claims warning in the receipt when processing manifests without holder binding. (Worked example: unbound-claims warning — see Cookbook.)