Universal Manifest v0.4 Specification — Base

Working Draft — Preview. 10 June 2026.

This version: https://universalmanifest.net/spec/v0.4-preview/ Latest stable version: https://universalmanifest.net/spec/v0.3/ History: https://universalmanifest.net/spec/ Editors: Universal Manifest Working Group. Copyright © 2026 the Contributors to the Universal Manifest Specification, published under the W3C Software and Document License.

Working Draft — Preview. This document is not stable. It carries all normative content from v0.3 forward and adds Tier-0/Tier-1 baseline content for v0.4. Sections marked PREVIEW are not final and may change. For the current stable specification, see Universal Manifest v0.3.

Abstract

This specification defines the Universal Manifest, a portable state capsule. A Universal Manifest is defined by an abstract data model — a set of types, properties, and semantics that exist independently of any single serialization — together with production rules that specify how that abstract model is written into a concrete wire format. JSON-LD is the reference encoding used throughout this document and is the default format conforming implementations are expected to interoperate with; a second compact encoding (CBOR-LD) is defined in EXT-OPT to demonstrate format independence. Formulated as a hybrid of web publication metadata and web application parameters, the Universal Manifest gives developers and holders a standardized envelope to convey linked-data identity references, role permissions, device registrations, and pointers to canonical data sources.

The Universal Manifest is designed for local-first environments (venue edges, public displays) where evaluators must tolerate partial connectivity and rely on cached, verifiable state. Using this standard, user agents, smart displays, and network edges can securely interoperate without a continuous cloud connection, enabling seamless cross-context experiences.

Conformance Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in ALL CAPITALS, as shown here.

Status of This Document

This is a Working Draft — Preview. It is not stable. Universal Manifest v0.4 builds on the stable v0.3 specification, which established the evaluation contract, the six-stage evaluation sequence, encrypted inline facets, structured receipts, and the normative baseline for cross-DID binding, requiredTrustTier, and agent delegation. Version 0.4 is the production-candidate milestone.

This Base document carries the Tier-0/Tier-1 conformance surface. Features that a conformance claim adds above Tier 1, and capabilities orthogonal to the tier ladder, live in companion extensions (EXT-T1, EXT-T2, EXT-T3, EXT-OPT); the Base names each and points to it. Requirements in PREVIEW sections become final only after working-group review.

Because Universal Manifest is still in the v0.x line, minor-version bumps may include breaking changes reflected by a new version folder. For implementers, the v0.3 specification remains the stable baseline; run the Standalone Conformance Suite and review Conformance v0.3.

Changes from v0.3 (summary)

All v0.3 normative content is carried forward, with the single exception of the deprecated interpretedAs member, which is removed and replaced by the typed trustWeight field (EXT-OPT); a v0.3 manifest carrying interpretedAs degrades safely. v0.3 manifests remain parseable by v0.4 evaluators. The additions, one line each (mechanics in the cited document):

Credential binding (new normative, Tier 1+): holderBinding, presentationProof, livenessAttestation, the end-to-end claim-proof process, and credential-binding receipt fields — specified in EXT-T1. The Base carries the requirement and the field surface.
JWE algorithm constraints (new normative): a MUST-implement algorithm pair for encrypted facets — §2.4.
Stage-2 credential-binding verification sub-steps (new normative): woven into the Verify stage — summarized in §3.1.2, specified in EXT-T1.
statusRef resolution schema, cryptographic-requirements summary — EXT-OPT.
Envelope/wire additions (PREVIEW): manifest classes and the polymorphic envelope (§1.0.1); actorState, two-component devices, derived-variant sensor consent, receipt-as-class, trustWeight/category-trust — all specified in EXT-OPT, named here.
Format independence: abstract data model and production rules, plus ADM conformance — named in §1.7 and §4.5, specified in EXT-OPT.
Advanced trust and privacy profiles (PREVIEW): Tier-2 ZKP (EXT-T2), Tier-3 ceremony (EXT-T3), post-quantum signatures and selective-disclosure dual-track (EXT-T2).
Infrastructure (PREVIEW): bilateral session model, agent-delegation scope registry, profile registration, federation — EXT-OPT.

For the v0.2→v0.3 migration path, see the v0.3 specification.

1. Universal Manifest

A Universal Manifest is a cross-platform data envelope defined by an abstract data model (§1.7) and serialized through a production rule for a concrete format. It blends the semantic linkability of a Web Publication Manifest with the applied processing lifecycle of a Web App Manifest. Unless stated otherwise, the examples and member definitions in this section are expressed in the JSON-LD reference encoding; the same manifest MAY be produced in any other conformant encoding, such as CBOR-LD (EXT-OPT), without changing its meaning.

1.0. Terminology

The following terms are used normatively throughout this specification.

manifest — A Universal Manifest: the portable state capsule defined by this specification.
subject — The primary entity a manifest describes, identified by the subject member (§1.3.2).
holder — The party that assembles, signs, and presents a manifest. The holder controls selective disclosure (§3.1.3) and is the party bound by the holderBinding mechanisms (EXT-T1).
presenter — The party transmitting a manifest to an evaluator in a given interaction; usually the holder.
evaluator — The conformance class that consumes a manifest and applies the evaluation sequence (§3.1). Also called the verifier; it is the relying party applying the result. This specification uses "evaluator" uniformly.
issuer — The party that issued a credential carried as a claim or claimProof (§6.4.3).
attester — A party that asserts a cross-DID binding or other attestation an evaluator may trust by policy (§6.4.4).
resolver — A service that resolves manifest status or coordinates federated status (EXT-OPT).
status endpoint — The HTTP endpoint a signature.statusRef resolves to (EXT-OPT).
session — A time-bounded interaction; for bilateral exchanges, the object specified in EXT-OPT.
receipt — The structured, machine-readable record an evaluator produces (§3.3).
production / consumption — Serializing the abstract manifest into a wire encoding / parsing it back (§1.7).
sealed entry — An encrypted facet an evaluator cannot decrypt; recorded as present but not read (§3.1.4).
trust tier — One of the four claim-verification tiers (§6.4.2). The achieved tier (effectiveTrustTier) is distinct from a declared requiredTrustTier floor and from the interaction tier floor negotiated in a bilateral exchange (§6.4.6).
interactive presentation — A presentation made in response to a verifier-issued challenge (EXT-T1).

1.0.1. Manifest Classes and the Polymorphic Envelope PREVIEW

The Universal Manifest is a polymorphic envelope: a single fixed envelope shape carries many kinds of payload. The envelope members (§1.2), identity and lifespan members (§1.3), structural state members (§1.4), and integrity proof (§1.5) are common to every manifest. What a particular manifest is — identity capsule, device-capability descriptor, consent record, receipt — is determined by which facets, claims, consents, pointers, and reserved members it carries, not by a distinct schema per kind. This is the same extensibility model v0.3 already enables; v0.4 names it and states the rule explicitly.

A manifest class is a named, profile-defined combination of structural members an evaluator can recognize and act on. The discriminator for a class is its characteristic facet set: the presence of specific facet @type values, claim @type values, named structural members, and any additional top-level @type values a class profile declares alongside um:Manifest (for example um:Receipt). Evaluators MUST NOT rely on the top-level @type alone to determine a class beyond the required um:Manifest value; the discriminating members are the authoritative signal. A manifest MAY satisfy more than one class simultaneously.

Because classes are discriminated by member presence rather than a closed type enumeration, the envelope remains non-breaking and forward-compatible: an evaluator that does not recognize a class processes the members it understands and records the rest as present-but-unprocessed (§3.1.1). Every v0.3-conformant manifest is, by this rule, a valid v0.4 manifest of one or more classes. New manifest classes are defined by profile documents registered through the profile registration mechanism (EXT-OPT) under the domain category, and MUST NOT redefine or remove any common envelope member. An informative snapshot of classes currently surfaced by integration profiles is in EXT-OPT (Manifest Class Registry Snapshot).

Preview: Naming the polymorphic envelope and the discriminator rule is built on the editors' default (add; non-breaking). Working-group input is requested on whether the discriminator should remain member-presence-based or also admit an explicit optional manifestClass hint member.

1.1. Examples

A minimal Universal Manifest carries only the anchor, identity, and lifespan members plus a signature:

{
  "@context": ["https://universalmanifest.net/ns/v0.4"],
  "@id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "@type": ["um:Manifest"],
  "manifestVersion": "0.4",
  "subject": "did:example:123",
  "issuedAt": "2026-03-01T00:00:00Z",
  "expiresAt": "2026-03-02T00:00:00Z",
  "signature": {
    "algorithm": "Ed25519",
    "canonicalization": "JCS-RFC8785",
    "keyRef": "did:key:z6MkExample#keys-1",
    "publicKeySpkiB64": "MCowBQYDK2VwAyEA...",
    "created": "2026-03-01T00:00:00Z",
    "value": "base64url-encoded-signature-bytes"
  }
}

The signature values above are illustrative; see §1.6 for the full signature shape and signing procedure. Worked examples for every concept in this document are collected in the Cookbook.

1.2. Core Identity Members

Three properties — the manifest's contextReference, id, and type — identify and semantically anchor every manifest. They are defined here in the JSON-LD reference encoding, where they are expressed using the JSON-LD keywords @context, @id, and @type. The requirements apply to the corresponding abstract properties in any conformant encoding.

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, served at the versioned namespace URI; this version's context document, with its content hash, is reproduced in Appendix B and is normative for context integrity (§6.10).

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. Identities & Lifespans

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 [RFC3339] date-time production and SHOULD use UTC (Z).

1.4. Structural State Members

The manifest structure relies on domain-specific members akin to Web Publication linkages.

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).
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).

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. Signature Integrity

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. Signature Profile A: JCS + Ed25519

Signature Profile A is the baseline normative signature profile. It constrains the signature member to a deterministic, portable format suitable for local-first verification on constrained devices. (Introduced in v0.2; the required baseline in v0.3 and v0.4.)

Signature profiles are additive. Future versions MAY introduce additional profiles (e.g., post-quantum algorithms — see EXT-T2 — or W3C Data Integrity proofs). Evaluators verify the profiles they support; supplementary proof material from an unknown profile carried alongside a supported signature (for example, a postQuantumSignature during dual-signature migration) is safely ignored. A manifest whose only signature uses an unsupported profile is rejected.

1.6.1. Canonicalization and Algorithm

Signature Profile A uses JSON Canonicalization Scheme (JCS, RFC 8785) for canonicalization and Ed25519 [RFC8032] for signing. Signature values are encoded as base64url [RFC4648]. 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 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:

Start with the complete JSON-LD production of the manifest (the reference encoding).
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).
Canonicalize the remaining object using JCS (RFC 8785), producing a UTF-8 byte sequence.
Compute the Ed25519 signature over those bytes.
Set the signature property on the manifest with the fields defined above.

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".
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.

1.7. Abstract Data Model and Production Rules

The manifest is defined by a serialization-independent abstract data model plus production rules that write that model into a concrete wire format, following the W3C DID Core pattern. The abstract data model is a set of properties and semantics; a production serializes it, a consumption parses it back. JSON-LD is the reference encoding used throughout this document and is the encoding implementations are expected to support for interoperation; a second compact encoding, CBOR-LD, is defined to demonstrate format independence.

This Base treats format independence at naming altitude: the manifest has an abstract model, JSON-LD is its reference encoding, and a signature is computed over the bytes of one production (so re-encoding requires re-signing). The full abstract-property table, the JSON-LD and CBOR-LD production rules, the signing-and-production rule, and context-integrity production details are specified in EXT-OPT (Abstract Data Model & Format Independence). Supporting the JSON-LD reference encoding alone is sufficient for full conformance (§4.5).

2. Entities and Facets

Universal Manifest adopts a compositional pattern allowing nested structures (facets mapping to specific entities), drawing from semantic web standards for interlinked resources.

2.1. um:Facet Module

A facet is a composable part grouped within a manifest's envelope. A facet object MUST contain:

@id — A URI uniquely identifying this facet within the manifest. MUST be present. The consent mechanism uses consents[].facetRef to match against facets[].@id, and the receipt records facet status by @id.
@type — MUST include "um:Facet".

A facet object SHOULD contain entity — a um:Entity object (§2.2) holding the facet's payload parameters. A facet without an entity is structurally valid but carries no payload. A facet object MAY contain name (a human-readable display label), ref (a URI routing to the facet's authoritative source), and requiredTrustTier (integer 0–3 overriding the manifest-level trust tier for this facet; can only raise the floor; see §6.4.5).

Facets are identified by @id for consent matching and receipt recording. The name field is a display label and MUST NOT be used as a unique identifier.

@type shape convention: Throughout this specification, a @type member MUST include the type value required for its object kind (for example um:Facet, um:Consent, um:Manifest) and MAY be a bare string when that is the sole type, or an array when multiple type values apply. Where a definition says a @type "MUST be" a single value, read it as "MUST include" under this convention.

Internationalization: Human-readable strings (name, label, displayName, reason, rotationReason) SHOULD be language-tagged using JSON-LD language maps where multilingual display is expected. Evaluators MUST NOT use display fields for matching.

(Worked example: plaintext facet — see Cookbook.)

2.2. um:Entity Base

The um:Entity is the base classification for all embedded configurations, representations, or localized states. An entity object MUST contain @id (a URI uniquely identifying the entity) and @type (an array of type strings including at least one type value). All other fields are profile-extensible; evaluators MUST ignore unknown entity fields for processing purposes but MUST NOT strip them before signature verification.

(Worked example: plaintext entity — see Cookbook.)

2.4. JWE Algorithm Constraints

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. Manifest Lifecycle and Caching

Parallel to the Web Application Manifest lifecycle, the Universal Manifest must be systematically processed, applied, and occasionally evicted from client edges.

3.1. Evaluation Sequence

When a user agent, smart edge, or any evaluating platform encounters a Universal Manifest, it MUST process the manifest through a six-stage evaluation sequence. Each stage produces a defined output that feeds the next. Implementations MAY short-circuit the sequence at any stage by emitting a rejection receipt (§3.3).

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:

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).
Freshness enforcement: reject if now > expiresAt or if issuedAt > expiresAt.
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. Selective disclosure is holder-controlled: the holder determines which facets are included in a given manifest instance. 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.

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).
accepted-partial — some facets processed; others rejected, sealed, or lacking consent.
rejected — the manifest failed a mandatory check (signature, freshness, structural validity, or required consent).

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.2. Caching Formulation

For constrained devices and public displays:

TTL Ejection: Caches MUST immediately evict or reject payloads where the system clock surpasses expiresAt.
Telemetry Minimization: Centralized logging platforms SHOULD stream only the @id string (and potentially a content hash), bypassing the full manifest payload to conserve bandwidth.
Identifier Rotation: Identifiers (@id) SHOULD be rotated on each issuance (a fresh random @id per manifest instance) to avert heuristic tracking.

3.3. Structured Receipts

A structured receipt is the terminal output of the evaluation sequence (§3.1). It provides an honest, machine-readable record of what the evaluator did with the manifest. Evaluators MUST produce a receipt for every manifest processed.

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", or "not-projected"), an OPTIONAL name, and an OPTIONAL reason. "trustTierUnsupported" records a facet withheld because its requiredTrustTier cannot be verified (§6.4.5). "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 keyed by facetId/consentRef); 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).

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.1.1. Credential Binding Status Fields

When the evaluator processes credential-binding mechanisms (Tier 1+, specified in EXT-T1), the receipt SHOULD record their outcomes using holderBindingStatus, presentationProofStatus, livenessStatus, crossDidBindingStatus, and effectiveTrustTier. Evaluators that do not implement credential binding omit these fields; their absence is equivalent to "absent". effectiveTrustTier is the highest trust tier the evaluator actually verified for the claims it relied on, per §6.4.2; a claim without a verified holderBinding contributes at most Tier 0. effectiveTrustTier is independent of the declared requiredTrustTier; the evaluator MUST NOT act on any item whose requiredTrustTier exceeds the effectiveTrustTier it achieved. Recording both makes the gap between declared and verified trust explicit. The exact value sets for these fields are specified in EXT-T1.

Preview decision: One open working-group decision remains on effectiveTrustTier's status — REQUIRED on every v0.4 receipt (recommended direction) versus SHOULD conditional on credential-binding support, as built here. Flag to revise.

(Worked example: structured receipt — see Cookbook.)

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 (Receipts-as-Class & Status Infrastructure).

3.4. statusRef Resolution Schema

signature.statusRef (§1.6.2) resolves to a status endpoint that reports whether a manifest instance is active, revoked, or suspended. The HTTP resolution procedure, response schema, status semantics, conditional-request/caching behavior, and error taxonomy are specified in EXT-OPT (Receipts-as-Class & Status Infrastructure). In the Base, an evaluator that implements revocation-aware verification follows that protocol; an evaluator that does not records revocationStatus: "unchecked" (§1.6.6).

3.5. Bilateral Session Model PREVIEW

In a bilateral exchange both parties present and evaluate manifests (§6.4.6). The bilateral session model — session objects, paired-receipt correlation via exchangeId, session identifiers (sessionId), session lifecycle states, and transport independence — is a protocol-layer concern specified in EXT-OPT. The Base carries the bilateral field surface it depends on: exchangeId and evaluatorId on receipts (§3.3.1), and the bilateral-exchange security model (§6.4.6).

4. Conformance

Conformance is defined against the abstract data model, not against any single serialization. An implementation conforms by correctly handling the abstract properties and semantics of a manifest after consuming it through at least one production rule; the JSON-LD reference encoding is the encoding implementations are expected to support for interoperation. The behavioral requirements below apply to the abstract manifest regardless of encoding (§4.5).

4.1. Evaluator Behavior

An evaluator MUST consume a manifest through a production rule it supports to obtain the abstract manifest, then validate its abstract properties and securely ignore unknown elements without raising fatal errors. Freshness (via expiresAt TTL) is an absolute rejection gateway; implementers MUST verify issuedAt <= expiresAt.

Evaluators claiming v0.4 conformance MUST implement the six-stage evaluation sequence (§3.1). Specifically, a conformant evaluator MUST:

Execute all six stages in order (Arrive, Verify, Project, Consent, Compose, Receipt).
Produce a structured receipt (§3.3) for every processed manifest.
Treat encrypted facets as sealed entries when it lacks a decryption key, recording them as present.
Respect requiredTrustTier declarations at the manifest, claim, and facet levels.

4.2. Holder Behavior

Holders generating the manifest MUST assign a globally stable identifier URI for the subject (preferably an established DID) and a random URI for the manifest root (@id). To shield clients from unbounded trust windows, holders MUST strictly bound expiresAt to a sensible interaction lifetime (hours or days). Holders MUST sign every manifest prior to distribution using Signature Profile A (§1.6) or a subsequent normative profile.

For local-first deployments where evaluators may verify without connectivity, holders SHOULD use an offline-resolvable keyRef method (for example did:key) so key resolution succeeds at the edge and identity assurance is not capped at Tier 0.

v0.4 adds these holder obligations:

Holders encrypting facets MUST use the baseline JWE algorithm pair (ECDH-ES+A256KW / A256GCM, §2.4.1) unless an alternative has been negotiated out-of-band.
Holders presenting any claim intended to be relied upon at Tier 1 or above MUST carry a holderBinding on that claim (EXT-T1).
When presenting a manifest in response to a verifier-issued challenge (an interactive presentation), the presenter MUST include a presentationProof (EXT-T1).

4.3. Bilateral Participant Behavior

A Conformant Bilateral Participant MUST implement both Evaluator Behavior (§4.1) and Holder Behavior (§4.2). In a bilateral exchange (§6.4.6), both parties independently evaluate the other's manifest. The interaction tier floor is the maximum of either party's requiredTrustTier — a negotiated floor distinct from the effectiveTrustTier each party records (§3.3.1.1).

4.4. Standalone Conformance Suite

Implementations validate conformance claims natively by testing against the official conformance/ suite — fixture validation (accepting valid stubs and correctly isolating/flagging malformed artifacts like missing contexts or expired manifests). Implementations claiming v0.4 conformance MUST satisfy the normative requirements of this specification. The standalone conformance suite is the canonical evidence mechanism; implementations SHOULD publish their suite results and claimed level per https://universalmanifest.net/conformance/v0.4/. The v0.4 suite extends the v0.3 suite with tests for newly normative features; preview sections have no conformance tests until their designs are finalized.

4.5. Conformance to the Abstract Data Model

The requirements in §4.1–§4.3 are stated in terms of the abstract data model and apply identically regardless of which production rule serialized a manifest. A conformant implementation MUST support at least one production rule and, for interoperation, SHOULD support the JSON-LD reference encoding; MUST consume supported representations into the abstract data model before applying behavioral requirements, and MUST reject an unsupported encoding rather than misinterpreting it; MUST preserve every abstract property across a production/consumption round-trip when it both produces and consumes an encoding; and MUST verify the integrity proof against the bytes of the production it consumed (a signature is bound to one encoding). Supporting only the JSON-LD reference encoding is sufficient for full conformance; supporting CBOR-LD (EXT-OPT) is OPTIONAL. The full ADM conformance detail is in EXT-OPT.

4.6. Status Endpoint Conformance

A conformant status endpoint is the conformance class that responds to signature.statusRef resolution. Its obligations (response schema, status semantics, conditional requests) are specified with the statusRef protocol in EXT-OPT. Resolver conformance (the federated-status conformance class) is deferred pending the working-group decision on whether federation moves to a companion specification.

4.7. Optional-Feature Matrix

Several capabilities are optional modules: an implementation that does not implement one still conforms, provided it observes the mandatory baseline behavior for that capability. The keyword below is the implementation obligation for the module itself.

Feature	Conformance	Mandatory baseline when not implemented
Encrypted-facet decryption (§2.3)	OPTIONAL	Sealed-entry handling is REQUIRED: record the facet as present-but-sealed; never infer its content.
Revocation-aware verification (EXT-OPT)	RECOMMENDED	Record `revocationStatus: "unchecked"`; do not grant revocation-gated trust.
Credential binding (EXT-T1)	OPTIONAL (REQUIRED for Tier 1+)	Record `holderBindingStatus: "absent"`; cap relied-upon claims at Tier 0.
CBOR-LD encoding (EXT-OPT)	OPTIONAL	Support the JSON-LD reference encoding; reject unsupported encodings rather than misinterpreting them.
Transparency anchoring (EXT-OPT)	OPTIONAL	Verify the manifest signature and proofs directly; do not require a transparency log.

The complete optional-feature matrix, including modules introduced by extensions, is consolidated in EXT-OPT.

5. Extensibility & Profiles

Echoing the extensibility models of generic W3C recommendations, proprietary manifest members can be injected via fully qualified URIs inside the linked @context. Because evaluators ignore unrecognized properties while preserving them (§3.1.1), domain-specific profiles do not compromise cross-system interoperability.

The extension model in brief. Universal Manifest grows by profiles: self-contained documents that add manifest classes, claim types, signature profiles, trust profiles, or binding profiles, each registered under a canonical um:profile:<category>:<name> identifier and each constrained never to redefine a common envelope member. The formal profile registration mechanism (the five-step IANA-style process, the category scheme, conflict resolution, deprecation, and registry hosting) is specified in EXT-OPT.

Extensions Index. This document set comprises the Base plus the following companion documents:

Document	Scope	Registry category emphasis
EXT-T1 — Tier-1 Binding Profile	Credential-binding mechanics that satisfy the Tier-1 requirement: holder binding, presentation proof, liveness, the end-to-end claim-proof path, Stage-2 sub-steps, binding receipt fields.	`binding`, `trust`
EXT-T2 — Tier-2 Cryptographic-Binding Profile	Zero-knowledge cross-DID proof profiles (2A/2B), the BBS+ unlinkable selective-disclosure track, and post-quantum signature migration.	`trust`, `signature`
EXT-T3 — Tier-3 Multi-Party Ceremony Profile	The multi-party ceremony model, signer-role taxonomy, and threshold-protocol guidance.	`trust`
EXT-OPT — Optional-Feature Profiles	Tier-orthogonal optional capabilities: abstract data model & CBOR-LD, statusRef protocol, receipts-as-class, bilateral sessions, federation, profile registration, `trustWeight`/category trust, extended `devices`/`actorState`/sensor-consent schemas, crypto-requirements summary, class registry snapshot.	`domain`, `signature`, all
Cookbook	All worked examples, by scenario, tagged by tier. (Informative.)	—

6. Security Considerations

Universal Manifest v0.4 defines a mandatory signature profile, an additive tiered trust model, and resource-limit guidance. This section specifies the security properties these mechanisms provide and the threats they mitigate. The cryptographic constructions that realize the higher tiers are specified in the tier extensions; this section states the properties and the Tier-0/Tier-1 requirement surface.

6.1. Signature Limitations

Implementers MUST use Signature Profile A (§1.6) or a subsequent normative profile for production deployments. The v0.1 permissive signature format MUST NOT be relied upon for tamper protection.

6.2. TTL Enforcement

Bounding the expiresAt timeline is the primary defense against presentation replay spoofing. For interactive presentations, the presentationProof mechanism (EXT-T1) additionally binds a presentation to a specific verifier and challenge, preventing replay within the TTL window.

6.3. Resource Limits

Denial-of-Service vectors from inflated arrays or recursion SHOULD be countered with hard limits on payload ingestion. Evaluators SHOULD enforce at least the following defaults and MUST document any deviation in their conformance claim: maximum manifest size 1 MB; maximum nesting depth 10 levels; maximum array length 1,000 entries.

6.4. Identity Binding and Claim Authenticity

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. 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.

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 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; 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.

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.

(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, signer-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. Agent Delegation

The um:agentDelegation pointer (§1.4.5) declares that the manifest holder has delegated session authority to an agent (a bot, assistant, or automated process) acting on the subject's behalf.

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; evaluators MUST reject expired delegations). 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.)

6.6. Credential Binding Security Considerations

Credential binding is the set of mechanisms that turn the Tier-1 requirement into a verifiable property: holderBinding (proving the presenting subject is the credentialed holder), presentationProof (proof-of-possession binding a presentation to a specific verifier and moment), and livenessAttestation (evidence of recent interactive human authentication), together with their security considerations (BBS+ pseudonym scope, ZK trusted-setup, reciprocal-control limitations, and v0.3 backwards compatibility). This entire subsystem is specified in EXT-T1. The Base names it, requires it for Tier 1+ (§6.4.2, §4.2), and carries its field surface on claims (§1.4.3) and receipts (§3.3.1.1).

6.7. Post-Quantum Signatures PREVIEW

Post-quantum signature migration (candidate algorithms ML-DSA, SLH-DSA, FN-DSA, and a dual-signature migration path carrying a postQuantumSignature alongside the classical signature) is forward-looking cryptography for high-assurance deployments. It is specified in EXT-T2. The Base reserves the behavior at naming altitude: a postQuantumSignature, when present, is excluded from the signing input (§1.6.3) and is safely ignored by an evaluator that does not implement the profile (§1.6).

6.8. Category Trust and `trustWeight` PREVIEW

The typed trustWeight field (replacing the deprecated interpretedAs: "hint-only" enum) and the category-trust claim split (operator identity, service-category claim, category attestation, urgency claim) are specified in EXT-OPT. The Base records only that interpretedAs is removed and replaced by trustWeight (a v0.3 manifest carrying interpretedAs degrades safely, with trustWeight defaulting to "hint").

6.9. Cryptographic Requirements Summary PREVIEW

The consolidated mandatory-to-implement / recommended / optional / future table of all algorithms and cryptosuites referenced across the document set is maintained in EXT-OPT, so it can be updated as profiles are added without editing the Base. The Base's own mandatory-to-implement floor is: Ed25519 + JCS for signatures (§1.6) and ECDH-ES+A256KW / A256GCM for encrypted facets (§2.4.1).

6.10. Context Integrity

Because the meaning of every term in a manifest is fixed by its @context (§1.2.1), an evaluator MUST resolve the declared version namespace to a pinned, content-hashed context document rather than fetching an arbitrary remote context at evaluation time. The normative context document for this version, with its content hash, is reproduced in Appendix B. An evaluator MUST NOT alter term semantics based on an unpinned or substituted context, and MUST reject a manifest whose @context cannot be matched to a context it trusts. (Context-integrity production details — how the hash is computed and carried across encodings — are in EXT-OPT.)

7. Privacy Considerations

Universal Manifest is built so that a holder reveals only what an interaction requires, and so that the act of revealing does not become a durable tracking signal. The baseline privacy model rests on several properties already normative in this document:

Opaque, rotating identifiers. The manifest @id MUST be opaque and free of PII (§1.2.2) and SHOULD be rotated per issuance (§3.2), so manifest instances are not trivially linkable.
Holder-controlled minimal disclosure. Disclosure is holder-controlled and projection-scoped (§3.1.3): a holder includes only the facets an interaction needs, and a withheld facet is not projected, never evidence of absence.
Sealed entries. Encrypted facets (§2.3) let a holder carry data that only designated recipients can read; every other evaluator records the facet as present-but-sealed and MUST NOT infer its content.
The privacy–binding tension. Stronger identity binding (Tier 1+) improves assurance but can increase correlatability. Holders SHOULD prefer the least-linkable binding adequate to the interaction, and SHOULD omit long-lived correlators (such as a hardware deviceAttestation) from session-only or pseudonymous manifests (§1.4.6). The unlinkable (BBS+) selective-disclosure track that resolves much of this tension is specified in EXT-T2.
Consent as a privacy control. The Consent stage (§3.1.4) is itself a privacy mechanism: facet data may be used only within an explicit, in-window, scope-and-purpose-matched grant, and purpose binding prevents silent re-use of data across purposes.

On top of those properties, the following baseline privacy obligations apply to any conformant deployment:

Sealed-entry forward secrecy. Recipient revocation (§2.3.4) governs future issuances only: re-encrypting on revocation cannot un-share copies already distributed, and a revoked recipient retains the ability to decrypt every encrypted facet it already received. Holders SHOULD NOT rely on recipient revocation to withdraw access to data already conveyed.
Status-resolution correlation. Resolving signature.statusRef (§3.4) reveals to the status provider which evaluator is checking which manifest, and when — the classic credential phone-home correlation risk. Evaluators SHOULD mitigate this by respecting the nextCheck caching interval, by preferring herd-privacy status mechanisms such as the W3C Bitstring Status List (EXT-OPT), by spreading queries across federated resolvers (EXT-OPT), and by tolerating offline operation rather than blocking on a live status fetch.
Receipt minimization. Receipts (§3.3) are durable records of where a subject presented a manifest, carrying manifestId, facet identifiers, timestamps, and optionally evaluatorId. Receipts SHOULD carry the minimum facet detail needed for accountability, and retention SHOULD be bounded. Receipt chains SHOULD be signed with session-scoped keys (EXT-OPT) to avoid creating a long-lived correlator across unrelated interactions.
Data protection. The privacy considerations in this specification identify relevant data-protection provisions but do not constitute a Data Protection Impact Assessment. Deployers operating under GDPR or equivalent frameworks MUST conduct their own assessment for cross-DID binding operations, cross-border attester data flows, and mandatory binding requirements.

7.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.

8. Federation PREVIEW

Federation — resolver coordination, status-check distribution, cache invalidation, availability and failover, and manifest forwarding across multiple resolver operators — is a protocol-layer infrastructure concern that evolves independently of the envelope. It is specified in EXT-OPT. The Base depends on it only at naming altitude: a signature.statusRef (§1.6.2) may resolve through a federated resolver, but a Tier-0/Tier-1 evaluator treats status resolution as the single-endpoint protocol referenced in §3.4.

Acknowledgements

The Universal Manifest builds on the Web Publication Manifest and Web Application Manifest traditions, the W3C Decentralized Identifiers and Verifiable Credentials work, and the IETF JOSE/COSE and SD-JWT efforts. The editors thank the working group and integration-profile contributors.

9. References

This Base cites the references required to implement the Tier-0/Tier-1 surface. Extension-only references travel with their extension.

9.1. Normative References

[RFC 2119] Key words for use in RFCs. https://www.rfc-editor.org/rfc/rfc2119
[RFC 8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. https://www.rfc-editor.org/rfc/rfc8174
[RFC 3339] Date and Time on the Internet: Timestamps. https://www.rfc-editor.org/rfc/rfc3339
[RFC 8032] Edwards-Curve Digital Signature Algorithm (EdDSA). https://www.rfc-editor.org/rfc/rfc8032
[RFC 8785] JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
[RFC 4648] The Base16, Base32, and Base64 Data Encodings. https://www.rfc-editor.org/rfc/rfc4648
[RFC 7516] JSON Web Encryption (JWE). https://www.rfc-editor.org/rfc/rfc7516
[JSON-LD11] JSON-LD 1.1. https://www.w3.org/TR/json-ld11/
[DID-CORE] Decentralized Identifiers (DIDs) v1.0. https://www.w3.org/TR/did-core/

9.2. Informative References

[DPV] W3C Data Privacy Vocabulary. https://w3c.github.io/dpv/
[VC-DATA-MODEL] Verifiable Credentials Data Model v2.0. https://www.w3.org/TR/vc-data-model-2.0/

Additional references (BBS+, SD-JWT, FROST, ML-DSA/SLH-DSA/FN-DSA, MULTIFORMATS, OPENXR, WEBAUTHN, TPM2, and others) are cited where used in EXT-T1, EXT-T2, EXT-T3, and EXT-OPT.

10. IANA Considerations

10.1. Media Type Registrations

This specification registers the media type application/manifest+ld+json for the JSON-LD reference encoding of a Universal Manifest, with the versioned context namespace as the controlling vocabulary. The compact-encoding media type for CBOR-LD is registered with the CBOR-LD production rule in EXT-OPT.

10.2. Registry Change Control

Change control for Universal Manifest media types and for the profile registry rests with the Universal Manifest Working Group, per the profile registration mechanism (EXT-OPT).

Appendix B. Versioned Context Document (Normative Reference)

The full term definitions for v0.4 are fixed by the versioned context document served at https://universalmanifest.net/ns/v0.4. That document, together with its content hash, is the normative reference for context integrity (§6.10): an evaluator pins this content-hashed copy rather than fetching an arbitrary remote context at evaluation time. The context document defines the um: term set (um:Manifest, um:Facet, um:Entity, um:Consent, um:Receipt, um:Device, the um:reason: and um:profile: registries, and the structural member terms) over the base IRI https://universalmanifest.net/ns/um#. The verbatim context body and its multihash are reproduced in the published specification artifact; implementations MUST verify the hash before trusting the term definitions.

(Appendix A — Manifest Class Registry Snapshot — is informative and PREVIEW; it is relocated to EXT-OPT. Appendix C — Complete Worked Example — is informative and relocated to the Cookbook.)

End of Base. To implement above Tier 0, continue with EXT-T1. For concrete payloads, see the Cookbook.

Universal Manifest v0.4 — Base Specification

Tier-0 / Tier-1 Core · Working Draft (Preview)

11 June 2026