1.2.1. @context member (abstract property contextReference)

The @context member establishes the semantic definitions of terms used within the manifest. It MUST include the Universal Manifest namespace for the specification version being implemented (e.g., https://universalmanifest.net/ns/v0.4).

The namespace URI is versioned. Manifests conforming to this specification MUST use https://universalmanifest.net/ns/v0.4. Evaluators that support an earlier version MAY process manifests declaring it; an evaluator processing a v0.3 manifest under this specification applies the v0.4 evaluation sequence with the backwards-compatibility rules of EXT-T1.

The um: prefix used throughout (in @type values such as um:Manifest and registry identifiers such as um:reason:) expands to the IRI https://universalmanifest.net/ns/um#. The full term definitions for a given version are fixed by that version's context document, identified by the versioned namespace URI (and, upon publication, served there); this version's context document, with its content hash, is reproduced in Appendix B and is normative for context integrity (§6.10). Until publication, the normative copy is spec/v0.4/schema.jsonld in the specification repository.

1.2.2. @id member (abstract property id)

Holders MUST generate an @id member as a globally unique opaque identifier (e.g., urn:uuid:<uuidv4>). The @id value MUST NOT contain personally identifiable information.

1.2.3. @type member (abstract property type)

The @type member indicates the document type classifying the resource. It MUST include the value um:Manifest.

1.3.1. manifestVersion member

manifestVersion (string, REQUIRED): The version of the Universal Manifest specification this manifest conforms to. For v0.4 conformant manifests, the value MUST be "0.4". Evaluators MUST check that they support the declared version before processing — meaning a defined processing path exists, either native support or, for v0.3, the compatibility path of EXT-T1.

1.3.2. subject member

The subject member is REQUIRED. It specifies the primary entity (user, app, venue) the manifest describes, and MUST contain a stable identifier URI (e.g., a Decentralized Identifier / DID).

1.3.3. issuedAt and expiresAt members

Both issuedAt and expiresAt are REQUIRED. They formulate the bounding constraints (TTL) for the manifest's validity. All date-time values in this specification MUST conform to the RFC 3339 [RFC 3339] date-time production and SHOULD use UTC (Z).

1.4.1. facets member

The facets member organizes extended functional blocks (um:Facet), packaging verifiable capabilities, metadata subsets, or configuration modules. The abstract facets property is a list of facet objects; when present, it MUST be expressed as a JSON array in the JSON-LD reference encoding.

1.4.2. Structural State Arrays (claims, consents, pointers, devices)

These arrays group operational contexts representing permissions, deployed hardware targets, and external data reference pointers connected to the subject. Each array is a top-level structural member. All structural state members (facets, claims, consents, devices, pointers) are OPTIONAL; when absent, evaluators MUST treat them as empty arrays.

The manifest MAY also include the top-level member requiredTrustTier — an integer (0–3) specifying the minimum trust tier an evaluator MUST satisfy before acting on this manifest. OPTIONAL; default 0. See §6.4.5.

1.4.3. claims Array Schema

The claims array contains zero or more claim objects, each a statement about the manifest subject issued by the manifest signer or an external party. Evaluators process claims per the tiered trust model (§6.4.2) and the evaluation sequence (§3.1).

A base claim object MUST contain:

• @type — A string identifying the claim type. MUST be present. Specialized claim types (e.g., "identity.crossDidBinding") use this field to declare their schema.
• issuer — A DID or URI identifying the entity that asserts the claim. MUST be present. When the manifest signer is the issuer, this field MUST match the manifest subject or the signing key's controller.

A base claim object MAY contain:

• @id — An opaque identifier for this claim entry. RECOMMENDED when receipts or warnings reference the claim.
• subject — DID or URI of the entity the claim is about. When absent, the manifest-level subject is implied.
• issuedAt / expiresAt — RFC 3339 date-times. Evaluators SHOULD reject expired claims.
• claimProof — A Verifiable Presentation, attestation proof object, URI reference, or array of proof entries enabling Tier 1 verification (§6.4.3). When an array, each entry is independently verifiable.
• holderBinding — An object declaring how this claim is cryptographically bound to the manifest subject. REQUIRED for Tier 1 and above; OPTIONAL for Tier 0. The mode field MUST be one of "sd-jwt-kb", "bbs-holder-commitment", or "reciprocal-control". The binding verification procedure and mode-specific fields are specified in EXT-T1.
• requiredTrustTier — Integer (0–3) declaring the minimum trust tier for this claim (§6.4.5).

Specialized claim types extend the base schema by adding type-specific fields; the @type field determines which additional fields are expected. Evaluators encountering an unrecognized @type MUST treat the claim as unprocessable (present but unverifiable above Tier 0). The identity.crossDidBinding claim type is defined in §6.4.4.

(Worked example: base claim object — see Cookbook.)

1.4.4. consents Array Schema

The consents array contains zero or more consent entry objects, each recording a permission grant governing how an evaluator may act on specific facets. The Consent stage (§3.1.4) uses these entries to determine whether processing a facet is authorized.

A consent entry MUST contain:

• @id — A URI uniquely identifying this consent entry. MUST be present (used for receipt recording).
• @type — MUST include "um:Consent".
• facetRef — A string matching the @id of the facet this consent governs. This is the linking mechanism between a consent entry and its target facet.
• scope — An array of scope strings defining authorized operations (e.g., "read", "display", "cache", "process", "forward"). These are deployment-defined; this specification does not enumerate a closed set. Evaluators MUST NOT perform any operation not literally present in scope (fail closed), except where an optional profile defines a strictly-narrowing implication rule that the deployment documents in its conformance claim (e.g. the sensor derivation-tier rule, EXT-OPT §O9.1).
• purpose — A string declaring the stated purpose for data use (e.g., "session-personalization", "age-verification"). Evaluators MUST verify that their intended use falls within the declared purpose. Purpose comparison is exact string equality unless both parties support a shared vocabulary (e.g., the W3C Data Privacy Vocabulary [DPV]), in which case an evaluator MAY treat a narrower stated use as falling within a broader granted purpose per that vocabulary's hierarchy; deployments doing so MUST document it in their conformance claim.
• grantedAt — RFC 3339 date-time when consent was granted.
• expiresAt — RFC 3339 date-time when consent expires. Evaluators MUST treat expired consent as absent consent.

A consent entry MAY contain:

• grantor — DID or URI of the granting entity. When absent, the manifest subject is implied.
• withdrawnAt — RFC 3339 date-time of withdrawal. When present, the consent is no longer active regardless of expiresAt; evaluators MUST treat it as absent consent.
• conditions — An array of condition strings imposing additional constraints (e.g., "offline-only", "no-third-party-sharing"). Deployment-defined. Evaluators MUST NOT process a facet governed by a condition they do not recognize or cannot enforce (fail closed).

When a facet has no matching consent entry, the evaluator MUST record the facet status as "consent-missing" and MUST NOT process the facet's data. When the consents array is empty or absent, evaluators MUST treat all facets as lacking consent, unless the deployment operates under a consent model external to the manifest (e.g., a pre-negotiated bilateral agreement); such external models are outside this specification's scope.

The derived-variant sensor-consent vocabulary (per-sensor consent keys with purpose binding, for spatial-computing sensors) extends this base schema and is specified in EXT-OPT.

(Worked example: consent entry — see Cookbook.)

1.4.5. pointers Array Schema

The pointers array contains zero or more pointer objects, each referencing an external data source, delegation relationship, or canonical resource connected to the subject. Pointers are typed; the @type field determines semantics and expected fields.

A base pointer object MUST contain @type (a string identifying the pointer type; MUST be present) and target (a URI referencing the external resource; MUST be present). Pointer types MAY define type-specific fields that replace the base target requirement. A base pointer object MAY contain @id, label, createdAt, and expiresAt (RFC 3339; evaluators SHOULD ignore expired pointers — with one exception: an expired um:agentDelegation pointer is not ignored but rejects the manifest, §6.5.1).

The um:agentDelegation pointer type, which declares delegated session authority, is defined in §6.5 and replaces the base target requirement with the fields of §6.5.1. Evaluators encountering an unrecognized pointer @type MUST record the pointer as present in the receipt but MUST NOT act on it.

1.4.6. devices Array Schema PREVIEW

The devices array registers hardware endpoints (XR headsets, NFC readers, smart displays, wearable sensors) associated with the subject. v0.3 reserved this member without defining its entries. v0.4 defines device entries as a two-component split — a long-lived, manufacturer-signed deviceAttestation component and a session-scoped, user-signed deviceCapability component — specified in full in EXT-OPT.

In the Base, the devices array is a named reserved structural member: it is part of the signed payload, so evaluators MUST include it when recomputing the signing input (§1.6.3) and MUST NOT discard it during Arrive-stage unknown-field handling. Evaluators that do not implement the device components MUST still preserve the array and record device entries as present-but-unprocessed.

1.4.7. actorState member PREVIEW

The actorState member is an OPTIONAL top-level object declaring who is operating the session (the human principal, a delegated agent, or a hybrid), bridging the um:agentDelegation pointer (§6.5) to session-state semantics. It is named here as a reserved optional member and specified in full in EXT-OPT. When present, actorState.principal MUST match the manifest subject; actorState is additive and non-breaking, and evaluators that do not implement it record it as present-but-unprocessed.

1.5.1. signature member

The signature member carries cryptographic proof that the manifest payload has not been tampered with since issuance. Every v0.4 conformant manifest MUST include a signature member conforming to Signature Profile A (§1.6). Future spec versions MAY introduce additional normative profiles; evaluators MUST reject manifests whose signature profile they do not support.

Unsigned manifests MAY exist as development artifacts but are not v0.4 conformant and MUST be rejected by conformant evaluators.

1.6.1. Canonicalization and Algorithm

Signature Profile A uses JSON Canonicalization Scheme (JCS, RFC 8785) for canonicalization and Ed25519 [RFC 8032] for signing. Signature values are encoded as base64url without padding [RFC 4648] (the JOSE convention; verifiers MUST NOT require, and SHOULD reject, padded values). This combination provides deterministic signing input without JSON-LD expansion or RDF canonicalization. The profile is defined against the JSON-LD reference encoding and signs the canonical bytes of that production; other production rules either reuse a profile defined against the abstract model or specify their own byte-level signing rule (§1.7).

1.6.2. Signature Shape

The signature object MUST contain, for this profile:

• signature.algorithm — MUST be "Ed25519".
• signature.canonicalization — MUST be "JCS-RFC8785".
• signature.keyRef — URI reference to verification key material (recommended: DID URL or HTTPS URL). MUST be present.
• signature.value — base64url-encoded (unpadded, §1.6.1) Ed25519 signature over the canonical bytes.

The following fields are OPTIONAL:

• signature.publicKeySpkiB64 — base64-encoded SPKI DER public key bytes for offline/fixture/local-first verification.
• signature.created — RFC 3339 date-time when the signature was produced.
• signature.statusRef — URI to status material for this manifest instance (the manifest identified by its @id; see the statusRef resolution schema in EXT-OPT). It conveys the status of the manifest, not of any key.
• signature.revocationCursor — monotonic status cursor/version string for cache-aware revocation checks.

Additional fields MAY exist for future profiles, but evaluators SHOULD rely on algorithm + canonicalization to decide whether they can verify a given signature. The signature property is not included in the signing input (to avoid circularity); statusRef and revocationCursor, when present, are revocation-policy metadata and do not alter the signing input.

(Worked example: Signature Profile A object — see Cookbook.)

1.6.3. Signing Input Procedure

To compute the signature for this profile:

1. Start with the complete JSON-LD production of the manifest (the reference encoding).
2. Remove the signature property entirely. Also remove presentationProof if present (a verification-time proof computed over the signing-input hash; see EXT-T1) and postQuantumSignature if present (see EXT-T2).
3. Canonicalize the remaining object using JCS (RFC 8785), producing a UTF-8 byte sequence.
4. Compute the Ed25519 signature over those bytes.
5. Set the signature property on the manifest with the fields defined above.

JCS presumes I-JSON-compatible input: the JSON-LD production consumed for signing MUST be an I-JSON document [RFC 7493], and a document with duplicate member names MUST be rejected at the Arrive stage (§3.1.1) — parser behavior on duplicates is otherwise implementation-defined, which would make the signing input ambiguous between two conformant verifiers.

This yields a stable, portable verification input for any implementation that supports JCS + Ed25519.

1.6.4. Evaluator Checklist

An evaluator implementing this profile MUST, in order: (1) confirm the document is a v0.x Universal Manifest (required fields present, @type includes um:Manifest); (2) enforce TTL (§3.1.2); (3) confirm profile support via the algorithm+canonicalization pair (§1.6.5); (4) resolve the verification key (see below); (5) recompute the signing input (§1.6.3); (6) verify the Ed25519 signature over the canonical bytes. If verification fails, the manifest MUST be rejected for use (MAY be retained for debugging).

Key resolution (step 4). The evaluator MUST attempt to resolve keyRef (method-specific; some methods such as did:key resolve locally without network):

• Resolution succeeds and publicKeySpkiB64 present → the resolved key MUST be byte-identical to the decoded publicKeySpkiB64; on mismatch, reject with rejected / signatureCheck: "invalid". Because DID resolution yields verification keys in method-specific representations (JWK, multibase/multicodec), the evaluator first converts the resolved key to its SPKI DER encoding — equivalently, compares the raw 32-byte Ed25519 public-key values — before the byte comparison.
• Resolution succeeds and publicKeySpkiB64 absent → use the resolved key.
• Resolution unavailable (offline/unreachable) and publicKeySpkiB64 present → the evaluator MAY verify against the embedded key but MUST record keyRefResolution: "unresolved", MUST NOT grant trust above Tier 0 on the basis of keyRef's identity, and SHOULD re-validate when connectivity returns.
• Resolution unavailable and publicKeySpkiB64 absent → the manifest cannot be verified and MUST be rejected for use (MAY be retained for retry).

Security Note: Without the byte-identity check, a malicious holder could bundle a keyRef pointing to a high-reputation DID while supplying their own key material in publicKeySpkiB64 (key substitution). The offline path caps identity assurance rather than blocking verification: integrity is still confirmed against the embedded key, but the keyRef identity MUST NOT be attributed to that key until resolution confirms the binding.

1.6.5. Profile Identification

Evaluators MUST treat the pair signature.algorithm + signature.canonicalization as the explicit profile identity. If the pair is unsupported, the manifest MUST be rejected, recording signatureCheck: "unsupported-profile". Evaluators MUST NOT reinterpret unknown pairs as the baseline profile.

1.6.6. Revocation-Aware Verification Extension

For evaluators claiming revocation-aware verification: if signature.statusRef is present, resolve status from that URI (see the resolution protocol in EXT-OPT); if signature.revocationCursor is present, use it to prevent stale-status acceptance and drive cache revalidation; if revocation status cannot be determined and policy requires active status, the manifest MUST be rejected for use. Evaluators that do not implement revocation-aware verification MUST report revocation status as unchecked and MUST NOT claim revocation-aware conformance.

2.3.1. Declaration

An encrypted facet declares its encrypted payload in place of (or alongside) a plaintext entity. The facet retains its plaintext @id and @type (um:Facet) so consent matching and receipt recording operate normally; the sensitive content is confined to the encrypted payload.

An encrypted facet MUST carry the facet member encryptionProfile with the value "jwe-inline-v1" (this profile's identifier). That member is the declaration that the facet's entity value is an encrypted payload rather than a plaintext um:Entity: the facet's entity value MUST be the JWE object of §2.3.2. An evaluator recognizes an encrypted facet by the presence of encryptionProfile: "jwe-inline-v1" and reads its payload as a JWE accordingly.

2.3.2. JWE Structure

The encrypted payload MUST be a JWE in General JSON Serialization [RFC 7516], carrying the standard JWE members (protected, recipients with per-recipient encrypted_key, iv, ciphertext, tag). The plaintext of the JWE is the JSON serialization of the facet's um:Entity payload. Per-recipient encryption allows a single encrypted facet to be readable by multiple designated evaluators, each decrypting with its own key. The baseline algorithm pair is defined in §2.4.

2.3.3. Key Rotation

Holders MAY rotate the content-encryption key by re-encrypting the payload and re-signing the manifest. A rotationReason display field MAY record why rotation occurred, and previousKid MAY record the kid the current content-encryption key replaced — both are display/audit metadata with no processing semantics. Because the manifest signature covers the encrypted payload, any change to the ciphertext requires re-signing.

2.3.4. Recipient Revocation

A holder revokes a recipient by re-encrypting the payload without that recipient's encrypted_key entry and re-signing. revokedRecipientKid MAY record the kid of the removed recipient entry, and revocationAction MAY record the action taken (e.g. "re-encrypted") — both are display/audit metadata with no processing semantics. Forward access to subsequently issued manifests is removed; a recipient retains the ability to decrypt manifest instances it already holds (encryption is not retroactive). Deployments requiring retroactive revocation MUST rely on the manifest TTL and revocation status, not on the encryption layer.

2.3.5. Per-Facet Cryptographic Isolation PREVIEW

A deployment claims per-facet isolation for a named set of encrypted facets when it represents — in its conformance claim, in a profile it implements, or to a relying party — that a party able to decrypt one facet in the set is not thereby able to decrypt another. The obligation binds only a deployment that makes the claim; it does not outlaw shared-key encryption in general. The claim is carried as a conformance-claim flag and adds no manifest wire member, keeping isolation in symmetry with the discipline (EXT-T1 §T1.3.2) that a gesture (or identifier) is not a proof of provenance.

Under an isolation claim, the following structurally-checkable invariants apply across the declared isolated set:

• No shared decryption-authorizing kid. The same recipients[].header.kid MUST NOT authorize decryption of more than one facet in the isolated set. The comparison is across facets[].entity.recipients[].header.kid for the facets in the declared set.
• No shared (CEK, IV). Two isolated facets MUST NOT reuse an initialization vector; identical iv across two facets in the set is a violation (IV reuse under a shared content-encryption key is catastrophic for A256GCM). The comparison is across facets[].entity.iv for the facets in the declared set.

These two are a cross-field structural rule of the same kind as the trust-tier floor check (§6.4.5).

Residual gap (necessary, not sufficient). Distinct kid strings and distinct iv values are NECESSARY but not sufficient for true key isolation. Because kid is opaque, two distinct kids can still name HKDF- or HD-derived children of one root secret; an evaluator cannot verify true key isolation or true derivation-labeling from manifest bytes. True isolation depends on deployment key custody and derivation that Universal Manifest does not attest. This residual is declarable and audited, never eliminated. The cryptographic property itself — that a grant to decrypt facet A yields no plaintext for facet B — is a behavioral property outside the structural conformance suite.

2.4.1. Baseline Algorithm Pair

For encrypted facets (§2.3), conformant implementations MUST implement the algorithm pair ECDH-ES+A256KW (key management) with A256GCM (content encryption). This pair is the mandatory-to-implement baseline ensuring interoperable decryption across implementations. Holders encrypting facets MUST use this pair unless an alternative has been negotiated out-of-band.

2.4.2. Evaluation Contract

An evaluator that implements encrypted-facet decryption MUST support the baseline pair. An evaluator encountering a JWE that declares an algorithm pair it does not support MUST treat the facet as a sealed entry (present but not read), exactly as it treats a facet for which it lacks a key. Additional algorithm pairs MAY be registered through the profile registration mechanism (EXT-OPT).

2.4.3. Algorithm Negotiation

When two parties negotiate an alternative algorithm pair out-of-band (for example, in a bilateral session), each MUST still be able to fall back to the baseline pair, so that a manifest remains decryptable by any conformant recipient that did not participate in the negotiation.

(Worked example: facet with JWE inline encryption — see Cookbook.)

3.1.1. Stage 1: Arrive

The manifest is received and its envelope structure becomes visible. The evaluator MUST consume the representation through a production rule it supports to obtain the abstract manifest, confirm the existence of the required abstract properties (contextReference, id, type, manifestVersion, subject, issuedAt, expiresAt, signature), and verify that type includes um:Manifest. The evaluator MUST ignore unknown properties for processing purposes but MUST NOT remove them prior to signature verification. After verification succeeds, unrecognized properties have no normative semantics and MUST NOT affect evaluation outcomes. If consumption or structural validation fails, the sequence terminates with a rejected receipt.

This ensures extension fields survive the verification boundary while having no effect on behavior: forward compatibility is preserved because evaluators do not act on unknown fields, but signature integrity is maintained because those fields remain in the signing input.

3.1.2. Stage 2: Verify

The evaluator MUST verify the manifest's cryptographic integrity and freshness:

1. Signature verification over the signing input defined by the production rule and declared signature profile (for the JSON-LD reference encoding under Signature Profile A, the JCS-canonicalized document per §1.6.3).
2. Freshness enforcement: reject if now > expiresAt or if issuedAt > expiresAt.
3. Revocation status resolution, if signature.statusRef is present and the evaluator implements revocation-aware verification (protocol in EXT-OPT).

If signature verification fails, the manifest MUST be rejected (MAY be retained for debugging).

Credential-binding verification sub-steps (Tier 1+). When the manifest relies on the credential-binding mechanisms for Tier 1 or higher assurance, the evaluator MUST additionally perform binding sub-steps 2a–2d (holder-binding, presentation-proof, liveness, cross-DID binding-proof) as part of this stage, each recording its outcome in the credential-binding receipt fields (§3.3.1.1). These sub-steps are specified in full in EXT-T1. Evaluators that do not implement credential binding skip them and record the corresponding statuses as "absent", capping relied-upon claims at Tier 0.

Evaluators SHOULD allow a clock-skew tolerance of no more than 60 seconds for issuedAt/expiresAt comparisons. Manifests with issuedAt more than 60 seconds in the future SHOULD be rejected with rejected and freshnessCheck: "stale". Deployments without NTP MAY configure wider tolerances but MUST document them in their conformance claim.

3.1.3. Stage 3: Project

The evaluator MUST extract only the facets, claims, pointers, and device entries relevant to its processing context. This is the bounded v0.4 selective minimum disclosure profile: each viewer, verifier, system, or use case receives only the minimum information it is allowed or needs to see for that interaction. Selective disclosure is holder-controlled: the holder determines which facets are included in a given manifest instance, scoped by the verifier/audience, purpose, use case, and consent context. The holder MUST NOT include unrelated high-sensitivity facets merely because they exist in the holder's source container.

The evaluator MUST NOT assume the manifest contains the complete set of the subject's facets. Facets not included are not absent — they are not projected for this interaction. This bounded Base profile establishes projection, consent gating, sealed-entry handling, and honest receipt reporting. It does not by itself claim per-encounter unlinkability, cover-slot indistinguishability, resolver-operator privacy, or absence of residual fingerprinting; those stronger guarantees require the Tier-2 / high-privacy tracks and additional conformance evidence.

3.1.4. Stage 4: Consent

The evaluator MUST evaluate per-facet consent records before acting on facet data. For each projected facet, it matches the facet's @id against consents[].facetRef values (§1.4.4):

• If a consents entry governs the facet, the evaluator MUST verify that consent scope, purpose, and expiry are satisfied: the intended operation MUST appear in the consent's scope array, the intended use MUST fall within the consent's declared purpose, and the current time MUST be within the validity window (at or after grantedAt, before expiresAt). If a withdrawnAt field is present, the consent is treated as absent.
• If a facet is encrypted (§2.3) and the evaluator lacks a decryption key, the evaluator MUST acknowledge the facet as a sealed entry (present but not read), recorded with the facet status "opaque" in the receipt (§3.3.1).
• If no consent entry governs the facet and it is not a sealed entry, the evaluator MUST record the facet status as "consent-missing".

Per-facet floors PREVIEW are evaluated together with consent in this stage: for a projected facet carrying a requiredLiveness floor (EXT-T1 §T1.3.1) or a requiredAssuranceClass floor (EXT-T1 §T1.3.3), the evaluator MUST verify the floor here and withhold the facet if it is unmet (recording assuranceInsufficient for an unmet assurance floor). When more than one withholding condition applies to the same facet, the evaluator reports the first failing gate in the order sealed-entry → consent → floors.

Evaluators MUST NOT process facet data when required consent is absent, expired, or withdrawn. Consent-evaluation outcomes map to receipt statuses as follows: a matching entry is satisfied (operation in scope, use within purpose, in-window, no unmet condition) → the facet is processed and its consent status is "valid"; no entry matches → "consent-missing"; a matching entry exists but operation is not in scope, use is not within purpose, or a condition is violated/unenforceable → "consent-denied" (with consent status "scope-mismatch", "purpose-mismatch", or "condition-violated"); a matching entry is expired or withdrawn → "consent-denied" with consent status "expired" or "withdrawn". The per-consent consentStatuses values are therefore "valid", "scope-mismatch", "purpose-mismatch", "condition-violated", "expired", and "withdrawn".

Write authorization. PREVIEW A write, update, or append to a facet is a distinct authorized operation, governed by a target-facet write-consent. The evaluator MUST NOT write unless a write operation is literally present in the governing consent's scope (consistent with the fail-closed-on-unrecognized-scope rule, §1.4.4), the purpose matches, and the consent is active. The governing consent is the one whose facetRef matches the target facet's @id. Absent such a consent, the evaluator MUST fail closed: it refuses the write and records "consent-missing" (no governing entry) or "consent-denied" with "scope-mismatch" (entry exists, write verb not in scope). Write authorization is not a new pipeline stage: it reuses this Stage-4 consent-matching machinery, applied at write time rather than only over the projected-facet read pass. New consent-scope operation tokens follow the <domain>.<capability> dot convention of the agent-delegation scope registry (EXT-OPT); legacy bare-word verbs (read/display/cache/process/forward) remain valid, so a scope such as ["read", "write.update"] carries intentional mixed punctuation. The candidate write-verb token family is: write.update (modify an existing facet's content), write.create (bring the pre-declared target facet into existence — the creation path below), and write.append (add content without modifying what exists); further write verbs register through the scope registry (EXT-OPT) like any other operation token.

When a write would create a facet that is not yet present (for example, durable agent memory — see §7.2), there is no @id for any existing consents[].facetRef to match, so under the plain Stage-4 rule the write is "consent-missing" and MUST be refused (fail closed). To authorize creation, the deployment MUST pre-declare a consent whose facetRef names the intended target facet @id (the holder commits the target @id ahead of the write). Write-replay protection uses the same anti-replay model as a presentation proof (EXT-T1): a write operation MUST carry a per-write nonce, or the evaluator MUST dedupe writes; a write performed under an unlock window (EXT-OPT) MUST still be individually replay-guarded. A successful write is recorded with the receipt facet status "written" (§3.3.1); a denied write reuses "consent-denied"/"consent-missing". The transport by which a write request and its per-write nonce reach the evaluator is deployment/protocol-layer by design; this stage defines the authorization and replay-guard requirements, not the carrier.

3.1.5. Stage 5: Compose

The evaluator composes the processing result into one of four outcome categories:

• accepted — all projected facets processed, all consent requirements satisfied, signature valid.
• accepted-with-warnings — accepted but one or more non-critical conditions were noted (e.g., revocation status could not be checked). An unsatisfiable manifest-level floor is not a non-critical condition — it produces rejected (below), not accepted-with-warnings.
• accepted-partial — some facets processed; others rejected, sealed, or lacking consent.
• rejected — the manifest failed a mandatory check (signature, freshness, structural validity — including cross-field constraints such as a below-floor tier declaration (§6.4.5) or an expired agent delegation (§6.5.1) — or required consent), or an unsatisfied required floor/tier applies at the manifest level and no processable items remain (for example, a manifest whose only facet is withheld because a required assurance/liveness floor or a facet-level requiredTrustTier cannot be met — the assurance-floor case is exercised by valid/manifest-locked-facet-below-floor.jsonld). Whether an application still renders anything after a rejected evaluation is an application-layer choice and does not change the receipt outcome.

The composed result MUST be machine-readable and MUST include per-facet status.

3.1.6. Stage 6: Receipt

The evaluator MUST produce a structured receipt (§3.3) that honestly records what the evaluator actually did, capturing the outcome of each preceding stage. Evaluators MUST NOT omit failed checks or suppress negative outcomes.

3.3.1. Receipt Fields

A receipt MUST include:

• @type — MUST include "um:Receipt".
• manifestId — the @id of the processed manifest.
• outcome — one of "accepted", "accepted-with-warnings", "accepted-partial", "rejected".
• signatureCheck — "valid", "invalid", "unsupported-profile", or "not-evaluated".
• freshnessCheck — "fresh", "expired", "stale", or "not-evaluated". "stale" indicates issuedAt is in the future relative to the evaluator's clock (beyond clock-skew tolerance).

A manifest rejected during Arrive (structural failure) terminates before signature/freshness checks; stages not reached record "not-evaluated".

A receipt MUST include a facetStatuses array (empty when the manifest has zero facets). Each entry is a per-facet status object with facetId (matching the facet's @id), status ("processed", "opaque", "consent-denied", "consent-missing", "trustTierUnsupported", "assuranceInsufficient", "not-projected", or "written"), an OPTIONAL name, and an OPTIONAL reason. "opaque" records a sealed entry — an encrypted facet the evaluator could not decrypt, acknowledged as present but not read (§2.3, §3.1.4). "trustTierUnsupported" records a facet withheld because its requiredTrustTier cannot be verified (§6.4.5). "assuranceInsufficient" records a facet withheld because the asserted/achieved authenticator assurance class is below the facet's requiredAssuranceClass floor (the locked-tier portable-unlock profile — EXT-T1 §T1.3.3); the facet's existence may be visible but its content is never released, parallel to "trustTierUnsupported". "written" records a successful write authorized under the write-consent rule (§3.1.4); reads keep "processed". "not-projected" indicates the evaluator's local policy expected a specific facet absent from the presented manifest; it is OPTIONAL and applies only when the evaluator has prior knowledge of the subject's schema.

A receipt SHOULD include, when applicable, the following fields (the receipt field surface a Tier-0/Tier-1 evaluator records): revocationStatus ("active" / "revoked" / "suspended" / "unchecked"); revocationReason (registry-coded); keyRefResolution ("resolved" / "unresolved", where "unresolved" caps keyRef-derived identity assurance at Tier 0); consentStatuses (per-consent status objects: each entry carries facetId, consentRef, status — one of the §3.1.4 per-consent values — and an OPTIONAL checkedAt, the RFC 3339 time the consent was evaluated); claimStatuses (per-claim status objects with claimRef, status ∈ {"verified", "unverified", "failed", "unprocessable", "trustTierUnsupported"}, optional tier/reason); unprocessedEntries (structural entries preserved but not acted on); processedAt; warnings (each with a registry code and a message); exchangeId and evaluatorId (REQUIRED on receipts produced in a bilateral session — EXT-OPT); receiptId; and receiptSignature (optional, following Signature Profile A).

When computing receiptSignature, apply the §1.6.3 signing-input procedure to the receipt object with receiptSignature taking the place of signature — it is removed from its own signing input (avoiding the circularity that a literal reading of §1.6.3, whose exclusion list names only signature, would otherwise create for a receipt that has no top-level signature). When a receipt is promoted to a first-class manifest (§3.3.2) and carries both a manifest signature and a receiptSignature, the receiptSignature is computed first and is then covered by the manifest signature (which excludes only signature, presentationProof, and postQuantumSignature, not receiptSignature).

Receipt signing is RECOMMENDED for accountability use cases but is not required for v0.4 conformance. Unsigned receipts are valid evaluation outputs but provide weaker non-repudiation.

3.3.2. Receipt as a First-Class Manifest Class PREVIEW

Beyond its role as the terminal output of a single evaluation, a receipt is itself a first-class manifest class (§1.0.1): a signed, portable record that can be chained, retained, and independently verified, carrying the common envelope members with @type including both um:Manifest and um:Receipt. This promotion is additive — an evaluator that only emits inline receipts remains conformant. The chain-integrity members (chainId/seq/prevHash), the typed event vocabulary, the structured reason registry, the session-scoped signing-key authorization, and the optional transparency-log anchoring profile are specified in full in EXT-OPT (O3, Receipt as a First-Class Manifest Class).

3.4.1. Current Policy-State Resolution Before Governed Action (Informative Composition)

This subsection is informative. It names a composition of existing normative machinery; the requirements themselves live in the cited sections and are not changed here.

Before a governed asset is used or a governed or agentic action proceeds, an evaluator often needs an answer to a plain-language question: is the consent, authorization, or status state carried by this manifest still current? Consent and authorization change over time — through renewal, withdrawal, expiry, supersession, and revocation — and a cached record can go stale. v0.4 resolves current policy state through the composition below. The composition applies to any governed asset or action — 3D assets, scans, media, digital replicas, embodied-person representations, and agentic actions alike — not to any single asset kind.

• Freshness bounds. issuedAt/expiresAt TTL enforcement (§3.1.2) bounds how stale any carried state can be; an expired manifest is rejected.
• Manifest-instance status. signature.statusRef resolution (§3.4, EXT-OPT) reports whether the manifest instance is active, revoked, or suspended, with monotonic cursor supersession and a nextCheck revalidation window. A superseding record is expressed today by revoking the old manifest instance and issuing a new one.
• Per-record status. A claimProof entry may carry its own statusRef (EXT-OPT), and key state is resolved through the key's DID document (§1.6.4); manifest status, claim status, and key status are distinct objects of resolution and are not conflated.
• Consent currency. Consent entries carry validity windows and withdrawal (grantedAt / expiresAt / withdrawnAt, §1.4.4); expired or withdrawn consent is treated as absent, and processing fails closed (§3.1.4).
• Delegation currency. An agent delegation expires at its expiresAt and may expose a livenessEndpoint for real-time delegation status (§6.5); absent that endpoint, the delegation is static for the manifest's TTL.
• Fail-closed / policy-gated behavior. When revocation status cannot be determined and local policy requires active status, the manifest is rejected for use (§1.6.6); an unreachable status endpoint is recorded as unchecked with a structured reason (EXT-OPT), and a facet whose consent cannot be verified is not processed (§3.1.4).
• Receipt evidence. The receipt records the resolution outcome — revocationStatus, per-consent consentStatuses, structured reason codes, and typed events such as consent-withdrawn / consent-expired (§3.3, EXT-OPT) — so the disposition of a governed action is auditable.

This composition is the bounded v0.4 behavior for current policy-state resolution. It does not yet define a unified policy-record resolution profile beyond these mechanisms — for example, a general supersession pointer between consent or authorization records, a normative policy-window taxonomy for deny (fail-closed) / escalate dispositions, or receipt reason codes specific to superseded and escalated outcomes. A candidate registered profile covering exactly those three pieces is drafted as the Current Policy-State Profile in EXT-OPT (PREVIEW, design-stage: its wire shape may change and it carries no conformance tests until finalized); deployments MAY also carry equivalent semantics as profile-defined extensions through the profile registration mechanism (EXT-OPT).

6.4.1. Bag of Claims Limitation

A Universal Manifest may contain claims from multiple issuers and references to multiple DIDs under a single subject. The manifest signature proves that the signer produced the manifest. It does not prove that the signer controls the subject DID (subject-signer binding), that the subject controls all DIDs mentioned in claims or facets (cross-DID control), or that an issuer actually issued a listed claim (claim authenticity) — claims[].issuer is a string assertion, not a verified provenance chain. Evaluators MUST NOT treat the presence of claims in a signed manifest as proof that those claims are authentic or that multiple DIDs are controlled by the same entity.

6.4.2. Tiered Trust Model

The specification defines four trust tiers for claim verification. Each tier is strictly additive — a claim verified at a higher tier also satisfies all lower-tier requirements. Higher tiers provide stronger guarantees but impose more user ceremony. The specification does not mandate a minimum tier; evaluators choose based on their threat model and acceptable user friction.

Tier 0 — Signature-only. Zero friction. Claims are self-asserted by the manifest signer; no external claimProof material is present. Suitable for low-stakes use cases where the evaluator has an out-of-band trust relationship with the signer. Evaluators claiming Tier 0 acceptance MUST verify the manifest signature per the declared profile. Tier 0 MUST NOT be used as sufficient assurance for Sybil-critical decisions.

Tier 1 — Attested or claimProof-backed. Low friction. Some or all claims carry external claimProof material (Verifiable Presentations) or an attested cross-DID binding claim (identity.crossDidBinding). Evaluators can verify specific claims against their issuers or evaluate attester trust. Evaluators claiming Tier 1 assurance MUST enforce attester trust policy and freshness/expiry checks on the proof material, and MUST validate the claimProof proof chain or the attester's cross-DID binding attestation before granting Tier 1 trust. Tier 1 additionally requires a verified holderBinding on each claim relied upon (EXT-T1): claimProof proves issuance, while holderBinding proves the presenting subject is the credentialed holder. (Exception: on an identity.crossDidBinding claim whose boundDids includes the manifest subject, presenter binding is established by the subject-signature key-authorization check together with attester or proof verification, so a separate holderBinding is OPTIONAL on such claims — EXT-T1 §T1.1.) Suitable for medium-stakes use cases (social identity, reputation, basic access control). (Binding mechanics: EXT-T1.)

Tier 2 — Cryptographic binding. Medium friction. Cross-DID control is cryptographically proven via zero-knowledge proof, without revealing private key material. Evaluators claiming Tier 2 assurance MUST verify the ZK proof before granting Tier 2 trust. Suitable for high-stakes Sybil-resistance. (Proof profile: EXT-T2.)

Tier 3 — Multi-party ceremony. High friction. Multiple keyholders (potentially different people, different locations) must co-sign, analogous to multi-sig wallets. Suitable for the highest-stakes organizational and financial contexts. (Ceremony model: EXT-T3.)

Evaluators MUST define their required trust tier based on their threat model. Evaluators MUST NOT extend trust from one DID in a manifest to another DID in the same manifest unless binding proof material (Tier 1 or Tier 2) is present for that specific DID pair.

Informative: the trust tiers grade binding strength — how strongly a claim is cryptographically tied to the presenting subject — not identity-proofing assurance. They are not equivalents of Levels of Assurance or of the NIST SP 800-63 IAL/AAL classes, and a tier MUST NOT be reported as satisfying such a level. (An orthogonal requiredAssuranceClass floor grades authenticator strength; its informative crosswalk to external assurance frameworks is in EXT-T1 §T1.3.3.)

6.4.3. claims[].claimProof Field

The claimProof field is an OPTIONAL property on any claim object, carrying proof material demonstrating claim issuance to the manifest subject. This field enables Tier 1 verification. It is named claimProof rather than evidence to avoid collision with the W3C Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL] evidence property.

claimProof MAY be a string (URI reference to a VP or attestation endpoint), an object (an embedded VP, attestation proof, or proof entry), or an array of proof entry objects, each independently verifiable (supporting claims backed by multiple independent proofs). Existing manifests with a single-value claimProof remain valid; the array form is additive and non-breaking.

When claimProof is an object or array element, each proof entry MAY carry proofType (RECOMMENDED values: VerifiablePresentation, DataIntegrityProof, sd-jwt-kb, pop-jws, evidence-pointer; if absent, inferred from structure) and proofPurpose (per W3C DID Core §5.3 [DID-CORE]; if absent, assume assertionMethod). Proof entries MAY contain additional properties (@type, verifiableCredential, proofValue, verificationMethod, statusRef); evaluators MUST preserve unrecognized properties.

Verification. At Tier 0 proof checks are OPTIONAL. At Tier 1+ the evaluator MUST verify the proof — the VP proof chain for an embedded object, fetch-and-verify (or record "unverified") for a URI string, and the conjunction of all entries for an array — and MUST enforce size limits of at most 50 KB per embedded VP and 500 KB total VP payload across all claims. The full verification procedure — the VP proof-chain steps, the claimproof-unresolved handling, the audience/challenge replay protections, and the end-to-end claim-proof path with key-authorization checks against DID Core verification relationships — is specified in EXT-T1. It is the mechanic that turns the Tier-1 requirement stated here into running code.

6.4.4. identity.crossDidBinding Claim

The identity.crossDidBinding claim type provides a pragmatic, trust-delegated mechanism for asserting that multiple DIDs are controlled by the same entity. It works within the existing claims[] array and requires no schema changes.

A crossDidBinding claim MUST contain @type ("identity.crossDidBinding"), issuer (inherited from the base claim schema), and boundDids (an array of DID strings asserted as controlled by the same entity; MUST contain at least 2 DIDs, one of which MUST match the manifest subject).

An attester-asserted binding — offered for Tier 1 evaluation on the strength of an attester's assertion rather than a cryptographic proof — MUST additionally contain attester (DID or URI of the attesting entity), attestationMethod (human-readable description of the verification method), and attestedAt (RFC 3339). When the claim instead carries a cryptographic bindingProof (EXT-T2) or ceremonyProof (EXT-T3), these three are OPTIONAL: the proof object carries the binding.

A crossDidBinding claim MAY contain claimProof (URI/object/array pointing to the attestation proof), expiresAt (attestation expiry; evaluators SHOULD reject expired attestations), bindingProof (a Tier 2 ZK proof — EXT-T2), and ceremonyProof (a Tier 3 ceremony proof — EXT-T3).

Evaluators MUST NOT treat the presence of a binding claim as proof of common control unless they trust the attester (for attester-asserted bindings) or have verified its cryptographic proof. Evaluators SHOULD maintain a configurable attester trust list. Multiple binding claims for overlapping DID sets are independent assertions, not cumulative proof.

(Worked example: cross-DID binding claim — see Cookbook.)

6.4.5. requiredTrustTier Declaration

A manifest MAY declare the minimum trust tier required for specific claims, facets, or the manifest as a whole via the requiredTrustTier field — an integer (0–3) indicating the minimum verification tier an evaluator MUST satisfy before acting on the associated data.

• Manifest-level: a top-level requiredTrustTier sets the floor for the entire manifest.
• Claim-level: a requiredTrustTier on an individual claim applies to that claim only.
• Facet-level: a requiredTrustTier on a facet applies to that facet only.

If a claim carries requiredTrustTier: 2 but the evaluator can only verify at Tier 1, the evaluator MUST treat that claim as unverified. If absent, the default is 0. The manifest-level value sets the floor; claim/facet-level values can only raise it, not lower it. A claim- or facet-level requiredTrustTier lower than the manifest-level value is a cross-field structural violation: evaluators MUST reject the manifest (rejected), exactly as for other structural-validity failures (§3.1.5).

If a manifest, claim, or facet specifies a requiredTrustTier for which the evaluator has no implemented verification profile (e.g., Tier 3, where the ceremony profile is under development — EXT-T3), the evaluator MUST treat the item as unverifiable and record it as "trustTierUnsupported" — in claimStatuses for claims, facetStatuses for facets, and crossDidBindingStatus for binding claims. The evaluator MUST NOT downgrade to a lower tier. The overall outcome is "accepted-partial" if other items can still be processed, or "rejected" if the unsupported tier applies at the manifest level or no processable items remain (§3.1.5).

(Worked example: manifest with requiredTrustTier — see Cookbook.)

6.4.6. Bilateral Exchange

In any transaction or interaction, both parties present a Universal Manifest to each other. Trust verification is inherently bilateral: Alice presents her UM to a venue and the venue verifies Alice's claims at the tier the venue requires; the venue presents its UM to Alice and Alice verifies the venue's claims at the tier Alice requires; a peer-to-peer exchange has both sides presenting and verifying simultaneously.

The interaction tier floor for an exchange is the maximum of what either party demands — a negotiated floor, distinct from the effectiveTrustTier each party verifies and records (§3.3.1.1). Asymmetric requirements are valid — each party sets its own requiredTrustTier independently. Two devices MAY exchange manifests via local transport (NFC, BLE, QR) and each independently verify the other's claims at the declared tier without a server. When asymmetric verification outcomes occur (one party cannot satisfy the other's required tier), each party MUST evaluate policy independently. For Sybil-critical or otherwise high-risk actions, parties MUST fail closed (deny the action) when required-tier checks are not satisfied; for lower-risk actions, parties MAY degrade to a restricted mode that excludes trust-transitive or high-impact operations.

(The bilateral session protocol — session objects, lifecycle, paired-receipt correlation — is specified in EXT-OPT.)

6.4.7–6.4.9. Advanced Binding Profiles (named; specified in extensions)

• §6.4.7 Tier 2 ZKP Proof Profile (PREVIEW) — the zero-knowledge proof profiles (Profile 2A: BBS+ linked-secret; Profile 2B: HD-derivation via Groth16) for cryptographic cross-DID binding, carried in the bindingProof field. Specified in EXT-T2.
• §6.4.8 Tier 3 Multi-Party Ceremony (PREVIEW) — the ceremony model, attester-role taxonomy, and threshold-protocol guidance, carried in the ceremonyProof field. Specified in EXT-T3.
• §6.4.9 Claim Proof Process — End-to-End Verification Path — the 7-step verification path from claim to trust decision, including key-authorization checks against W3C DID Core verification relationships. Specified in EXT-T1 (it is the connective procedure that ties §6.4.3, §6.4.4, and the Stage-2 sub-steps together).

6.5.1. Structure

A um:agentDelegation pointer MUST contain @type ("um:agentDelegation"), delegateType (one of "ai-agent", "bot", "proxy", "human-delegate"), delegatedBy (the DID of the delegating subject; MUST match the manifest subject), delegatedAt (RFC 3339, when delegation was granted), and expiresAt (RFC 3339). An expired delegation is a structural violation of the delegation pointer: evaluators MUST NOT honor it, and MUST reject the manifest (rejected) rather than process it with the delegation ignored — an expired grant of authority is not safely severable from a manifest presented under it (§3.1.5). This is an explicit exception to the base-pointer rule that expired pointers are ignored (§1.4.5). It MAY contain delegateId (the DID/identifier of the delegate; REQUIRED whenever the delegation is intended to be exercised), scope (an array of capability strings the delegate may exercise), and livenessEndpoint (a URI for real-time liveness/delegation status). Delegation defaults fail closed: when scope is absent or empty, evaluators MUST treat the delegation as granting no capabilities; when delegateId is absent, evaluators MUST NOT attribute the delegation to any specific agent and MUST NOT grant delegated authority on its basis. A delegation pointer referenced by actorState.delegationRef MUST carry an @id so the reference resolves.

6.5.2. Platform Guidance

Evaluators SHOULD display delegation status to other users when present, MAY require human-only sessions for high-stakes actions (financial, governance), and MAY query the livenessEndpoint for real-time status when available. Evaluators MUST treat the delegation pointer as static for the manifest's TTL if livenessEndpoint is absent. Platforms SHOULD also surface the operating executor to the relying party (see the actorState member, §1.4.7). The standardized agent-delegation scope registry (the namespace convention, the six core scope values, evaluator behavior for unrecognized scopes, and the registration procedure) is specified in EXT-OPT.

(Worked example: agent delegation pointer — see Cookbook.)

7.1.1. Selective Disclosure: Dual-Track Model PREVIEW

Manifest-level selective disclosure is offered along two tracks: Track A (baseline) — SD-JWT-style selective disclosure, the interoperable default — and Track B — BBS+ unlinkable derived proofs for privacy-critical deployments, which additionally prevent verifier-to-verifier correlation. The Base establishes Track A as the baseline selective-disclosure behavior consistent with holder-controlled projection above; the full dual-track model, and Track B's unlinkable-proof mechanics, are specified in EXT-T2.