Universal Manifest v0.3 Specification

1.1. Examples

The following is an example of a minimal Universal Manifest:

{
  "@context": [
    "https://universalmanifest.net/ns/v0.1"
  ],
  "@id": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "@type": ["um:Manifest"],
  "manifestVersion": "0.1",
  "subject": "did:example:123",
  "issuedAt": "2026-03-01T00:00:00Z",
  "expiresAt": "2026-03-02T00:00:00Z"
}

1.2. JSON-LD Core Members

1.2.1. @context member

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

1.2.2. @id member

The @id member provides a primary identifier. Issuers SHOULD generate @id as an opaque, offline-safe identifier (e.g., urn:uuid:<uuidv4>).

1.2.3. @type member

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

1.3. Identities & Lifespans

1.3.1. subject member

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

1.3.2. issuedAt and expiresAt members

The issuedAt and expiresAt members formulate the bounding constraints (TTL) for the manifest's validity. Both parameters are formatted as ISO 8601 / RFC 3339 date-time strings.

1.4. Structural State Members

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

1.4.1. facets member

The facets member organizes extended functional blocks (um:Facet), packaging specific verifiable capabilities, metadata subsets, or configuration modules.

1.4.2. claims, consents, devices, and pointers

These arrays group specific operational contexts representing permissions, deployed hardware targets, and external data reference pointers connected to the subject.

1.5. Signature Integrity

1.5.1. signature member

The signature member encapsulates cryptographic proofs of the manifest payload. In v0.1, its format is intentionally permissive. Version 0.2 introduces the first normative signature profile (see Section 1.6).

1.6. v0.2 Signature Profile: JCS + Ed25519

Version 0.2 introduces the first normative signature profile. This profile constrains the signature member to a deterministic, portable format suitable for local-first verification on constrained devices.

Signature profiles are additive. Future versions MAY introduce additional profiles (e.g., post-quantum algorithms or W3C Data Integrity proofs). Consumers verify the profiles they support and safely ignore unknown profiles.

1.6.1. Canonicalization and Algorithm

The v0.2 profile uses JSON Canonicalization Scheme (JCS, RFC 8785) for canonicalization and Ed25519 for signing. Signature values are encoded as base64url.

This combination provides deterministic signing input without requiring JSON-LD expansion or RDF canonicalization, matching the specification's "state capsule" usage where the JSON shape is the primary contract.

1.6.2. Signature Shape

The signature object MUST contain the following fields 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).
• 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 — ISO 8601 date-time indicating when the signature was produced.
• signature.statusRef — URI to revocation/status material for this signature.
• signature.revocationCursor — monotonic status cursor/version string for cache-aware revocation checks.

Additional fields MAY exist for future profiles, but consumers 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. The fields statusRef and revocationCursor, when present, are metadata for revocation-aware policy checks and do not alter the signing input.

{
  "signature": {
    "algorithm": "Ed25519",
    "canonicalization": "JCS-RFC8785",
    "keyRef": "did:key:z6MkAlice#keys-1",
    "publicKeySpkiB64": "MCowBQYDK2VwAyEA...",
    "created": "2026-04-01T10:00:00Z",
    "value": "base64url-encoded-signature-bytes"
  }
}

1.6.3. Signing Input Procedure

To compute the signature for this profile:

1. Start with the complete manifest JSON object.
2. Remove the signature property entirely.
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.

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

1.6.4. Verifier Checklist

A verifier implementing this profile MUST:

1. Confirm the document is a v0.x Universal Manifest (required fields present and @type includes um:Manifest).
2. Enforce TTL: reject for use if now > expiresAt; sanity-check issuedAt <= expiresAt.
3. Determine signature profile support: require signature.algorithm === "Ed25519", signature.canonicalization === "JCS-RFC8785", and a non-empty signature.value.
4. Obtain a public key: if signature.publicKeySpkiB64 exists, a consumer MAY use it directly (SPKI DER bytes, base64); otherwise, resolve signature.keyRef to public key material (method-specific, e.g., DID resolution or HTTPS fetch).
5. Recompute the signing input (remove signature, JCS canonicalize).
6. Verify the Ed25519 signature over the canonical bytes.

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

1.6.5. Profile Identification

Consumers MUST treat the pair signature.algorithm + signature.canonicalization as the explicit profile identity.

• If the pair is unsupported, the manifest MUST be rejected when strict verification is required by policy.
• Consumers MUST NOT reinterpret unknown pairs as the baseline profile.

1.6.6. Revocation-Aware Verification Extension

For consumers claiming revocation-aware verification:

1. If signature.statusRef is present, resolve status from that URI (or a configured equivalent).
2. If signature.revocationCursor is present, use it to prevent stale-status acceptance and to drive cache revalidation policy.
3. If revocation status cannot be determined and policy requires active status, the manifest MUST be rejected for use.

Consumers that do not implement revocation-aware verification MUST report revocation status as unchecked and MUST NOT claim revocation-aware conformance.

2.1. um:Facet Module

A facet is a composable part grouped within a manifest's envelope. A facet MUST explicitly declare @type: um:Facet. It MAY optionally declare a name for display purposes, a ref routing to its authoritative source, and an entity holding the payload parameters (um:Entity).

2.2. um:Entity Base

The um:Entity acts as the base classification for all embedded configurations, representations, or localized states. It MUST be resolvable through an @id URI and typed accordingly (@type array).

2.3. Encrypted Facets (JWE Inline Profile)

A facet MAY carry an encrypted entity payload using the JWE inline encryption profile. This enables the issuer to include sensitive data that is readable only by designated recipients while remaining opaque to all other consumers. Encrypted facets support the opacity principle: consumers acknowledge encrypted facets as present but cannot read their contents without the appropriate decryption key.

2.3.1. Declaration

To declare an encrypted facet, the facet MUST include the field encryptionProfile with the value "jwe-inline-v1". When encryptionProfile is present, the entity field MUST contain a JWE JSON Serialization object instead of a plain um:Entity.

2.3.2. JWE Structure

The entity value for an encrypted facet MUST conform to the following structure:

• protected — base64url-encoded JWE Protected Header. MUST specify alg (key agreement algorithm) and enc (content encryption algorithm).
• recipients — Array of recipient objects. Each recipient object MUST contain a header object with a kid field (key identifier, typically a DID URL) and an encrypted_key field (base64url-encoded wrapped content encryption key).
• iv — base64url-encoded initialization vector.
• ciphertext — base64url-encoded encrypted payload.
• tag — base64url-encoded authentication tag.

Consumers that do not possess a decryption key for any recipient entry MUST treat the facet as opaque. Consumers MUST NOT reject a manifest solely because it contains encrypted facets they cannot decrypt.

{
  "@type": "um:Facet",
  "name": "privateHealth",
  "encryptionProfile": "jwe-inline-v1",
  "entity": {
    "protected": "eyJhbGciOiJFQ0RILUVTK0EyNTZLVyIsImVuYyI6IkEyNTZHQ00ifQ",
    "recipients": [
      {
        "header": {
          "kid": "did:example:clinic#key-agree-1"
        },
        "encrypted_key": "base64url-encrypted-key-for-k1"
      }
    ],
    "iv": "base64url-iv-1",
    "ciphertext": "base64url-ciphertext-1",
    "tag": "base64url-tag-1"
  }
}

2.3.3. Key Rotation

When a recipient's key agreement key is rotated, the issuer MUST re-encrypt the content encryption key under the new key and update the recipients array. The JWE entity object MAY include the following fields to signal key rotation:

• previousKid — the kid of the replaced key.
• rotationReason — human-readable description of the rotation cause.

2.3.4. Recipient Revocation

To revoke a recipient's access, the issuer MUST remove the recipient from the recipients array, re-encrypt the payload with a new content encryption key, and re-issue the manifest. The JWE entity object MAY include the following fields to signal revocation:

• revokedRecipientKid — the kid of the revoked recipient.
• revocationAction — human-readable description of the revocation action taken.

When all recipients are revoked, the recipients array MUST be an empty array. The encrypted payload remains present but is not decryptable by any party.

3.1. Receiver Pipeline

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

3.1.1. Stage 1: Arrive

The manifest is received and its envelope structure becomes visible to the consumer. The consumer MUST parse the JSON document, confirm the existence of required properties (@context, @id, subject, issuedAt, expiresAt), and discard any unknown fields to preserve forward compatibility. If parsing or structural validation fails, the pipeline terminates with a rejected receipt.

3.1.2. Stage 2: Verify

The consumer MUST verify the manifest's cryptographic integrity and freshness. This stage includes:

1. Signature verification against the JCS-canonicalized payload per the declared signature profile (see Section 1.6).
2. Freshness enforcement: reject if now > expiresAt or if issuedAt > expiresAt.
3. Revocation status resolution, if signature.statusRef is present and the consumer implements revocation-aware verification.

If signature verification fails, the manifest MUST be rejected. The consumer MAY retain the manifest for debugging purposes.

3.1.3. Stage 3: Project

The consumer MUST extract only the facets, claims, and pointers relevant to its processing context. Projection is sender-controlled: the manifest issuer determines which facets are included in a given manifest instance. The consumer MUST NOT assume that the manifest contains the complete set of the subject's facets. Facets not included in the manifest are not absent — they are not projected for this interaction.

3.1.4. Stage 4: Consent

The consumer MUST evaluate per-facet consent records before acting on facet data. For each facet:

• If a consents entry governs the facet, the consumer MUST verify that consent scope, purpose, and expiry are satisfied.
• If a facet is encrypted (see Section 2.3), the consumer MUST acknowledge the facet as opaque if it lacks a decryption key. Opaque facets are recorded as present but not read.

Consumers MUST NOT process facet data when required consent is absent or expired.

3.1.5. Stage 5: Compose

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

• accepted — all projected facets processed, all consent requirements satisfied, signature valid.
• accepted-with-warnings — manifest accepted but one or more non-critical conditions were noted (e.g., revocation status could not be checked).
• accepted-partial — some facets were processed; others were rejected, opaque, or lacked 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 consumer MUST produce a structured receipt (see Section 3.3) that honestly records what the receiver actually did. The receipt captures the outcome of each preceding stage. Consumers MUST NOT omit failed checks or suppress negative outcomes from the receipt.

3.2. Caching Formulation

For constrained devices and public displays:

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

3.3. Structured Receipts

A structured receipt is the terminal output of the receiver pipeline (Section 3.1). It provides an honest, machine-readable record of what the receiver did with the manifest. Consumers MUST produce a receipt for every manifest processed through the pipeline.

3.3.1. Receipt Fields

A receipt MUST include the following fields:

• manifestId — the @id of the processed manifest.
• outcome — one of "accepted", "accepted-with-warnings", "accepted-partial", or "rejected".
• signatureCheck — result of signature verification: "valid", "invalid", or "unsupported-profile".
• freshnessCheck — result of TTL enforcement: "fresh" or "expired".

A receipt SHOULD include the following fields when applicable:

• revocationStatus — "active", "revoked", or "unchecked".
• facetStatuses — array of per-facet status objects, each containing a name (facet name), status ("processed", "opaque", "consent-denied", "consent-missing", or "not-projected"), and an optional reason string.
• consentStatuses — array of per-consent status objects indicating whether each consent requirement was satisfied.
• processedAt — ISO 8601 date-time when the receipt was produced.
• warnings — array of warning strings for the accepted-with-warnings outcome.

Note: The receipt schema is preliminary. Conformance fixtures for receipt validation are forthcoming.

{
  "manifestId": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "outcome": "accepted-partial",
  "signatureCheck": "valid",
  "freshnessCheck": "fresh",
  "revocationStatus": "unchecked",
  "facetStatuses": [
    { "name": "publicProfile", "status": "processed" },
    { "name": "privateHealth", "status": "opaque", "reason": "no decryption key" }
  ],
  "processedAt": "2026-05-19T12:00:00Z"
}

4.1. Consumer Behavior

A consumer platform parsing the manifest MUST validate structural parameters and securely ignore unknown elements without raising fatal invocation errors. Freshness (via expiresAt TTL constraints) is an absolute rejection gateway. Implementers MUST verify issuedAt <= expiresAt.

Consumers claiming v0.3 conformance MUST implement the six-stage receiver pipeline defined in Section 3.1. Specifically, a conformant consumer MUST:

1. Execute all six pipeline stages in order (Arrive, Verify, Project, Consent, Compose, Receipt).
2. Produce a structured receipt (Section 3.3) for every processed manifest.
3. Treat encrypted facets as opaque when the consumer lacks a decryption key, recording them as present in the receipt.
4. Respect requiredTrustTier declarations at the manifest, claim, and facet levels.

4.2. Issuer Behavior

Issuers 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, issuers MUST strictly bound expiresAt to a sensible interaction lifetime (e.g., hours or days).

4.3. Standalone Conformance Suite

Implementations validate conformance claims natively by testing against the official conformance/ suite—which includes fixture validation (accepting valid stubs and correctly isolating/flagging malformed artifacts like missing contexts or expired logic trees).

Implementations claiming v0.2 conformance MUST pass the standalone conformance suite and should publish their claimed level using the guidance at https://universalmanifest.net/conformance/v0.2/.

6.1. Signature Limitations

The v0.1 baseline format does not prescribe canonicalization or algorithm constraints. Version 0.2 addressed this gap by introducing the normative JCS + Ed25519 signature profile (see Section 1.6). Implementers MUST use the v0.2 signature profile 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 dictates the primary line of defense against presentation replay spoofing.

6.3. Resource Limits

Denial-of-Service vectors originating from disproportionately inflated arrays or recursion logic SHOULD be countered with hard limits on payload ingestion:

• Maximum memory serialization threshold: 1 MB
• Maximum recursion/nesting depth: 10 layers
• Array length maximums: 1,000 bounds

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 v0.2 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).
• That an issuer actually issued a claim listed in the manifest (claim authenticity). The claims[].issuer field is a string assertion, not a verified provenance chain.

Relying parties 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 higher-tier manifest also satisfies all lower-tier requirements. Higher tiers provide stronger guarantees but impose more user ceremony. The specification does NOT mandate a minimum tier; relying parties 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 relying party has an out-of-band trust relationship with the signer. Consumers 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). Relying parties can verify specific claims against their issuers or evaluate attester trust. Consumers claiming Tier 1 assurance MUST enforce attester trust policy and freshness/expiry checks on the proof material used for Tier 1 acceptance. Consumers MUST validate the claimProof proof chain or the attester's cross-DID binding attestation before granting Tier 1 trust. Suitable for medium-stakes use cases (social identity, reputation, basic access control).

Tier 2 — Cryptographic binding. Medium friction. Cross-DID control is cryptographically proven via zero-knowledge proof of cross-DID control. The subject demonstrates control of multiple DIDs without revealing private key material, using a ZK proof that the same entity controls the keys behind each DID. Consumers claiming Tier 2 assurance MUST verify the ZK proof before granting Tier 2 trust. Suitable for high-stakes Sybil-resistance use cases. At risk: this feature may be removed if implementations do not materialize before v0.4.

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. (Future: v0.4+.)

Relying parties MUST define their required trust tier based on their threat model. Relying parties 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. It carries a Verifiable Presentation or attestation proof demonstrating claim issuance to the manifest subject. This field enables Tier 1 verification.

The field is named claimProof rather than evidence to avoid collision with the W3C Verifiable Credentials Data Model v2.0 evidence property (VCDM section 9.2), which has overlapping but distinct semantics.

claimProof MAY be an embedded object (a VP or attestation proof) or a string (URI reference to a VP or attestation endpoint).

When present as an embedded object, the consumer SHOULD verify the VP proof chain: (a) VC signature validates to the stated issuer, (b) VP signature validates to the holder, (c) holder DID matches the manifest subject.

When present as a URI string, the consumer MAY fetch the VP for verification when network access is available. Consumers that cannot resolve the URI SHOULD report the claim as claimProof-unresolved rather than verified.

VPs used as claimProof SHOULD include domain (audience binding) and challenge (nonce) parameters to prevent cross-manifest replay.

Size limits: maximum 50 KB per embedded VP; maximum 500 KB total VP payload across all claims in one manifest.

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.

{
  "@type": "identity.crossDidBinding",
  "boundDids": ["did:key:z6MkAlice", "did:plc:alice-bsky"],
  "attester": "did:web:verify.example",
  "attestationMethod": "AT Protocol handle resolution",
  "attestedAt": "2026-03-15T10:30:00Z",
  "expiresAt": "2026-06-15T10:30:00Z"
}

Required fields:

• @type — MUST be "identity.crossDidBinding".
• boundDids — Array of DID strings asserted as controlled by the same entity. MUST contain at least 2 DIDs. One MUST match the manifest subject.
• attester — DID or URI of the entity attesting the binding.
• attestationMethod — Human-readable description of the verification method used.
• attestedAt — ISO 8601 timestamp of when the attestation was produced.

Optional fields:

• claimProof — URI or structured object pointing to the attestation proof.
• expiresAt — Attestation expiry. Relying parties SHOULD reject expired attestations.

Relying parties MUST NOT treat the presence of a binding claim as proof of common control unless they trust the attester. Relying parties SHOULD maintain a configurable attester trust list. Multiple binding claims for overlapping DID sets are independent assertions, not cumulative proof.

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. This field is an integer (0–3) indicating the minimum verification tier a relying party 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 relying party can only verify at Tier 1, the relying party MUST treat that claim as unverified. If absent, the default is 0 (no minimum required). The manifest-level value sets the floor; claim/facet-level values can only raise it, not lower it.

{
  "requiredTrustTier": 1,
  "claims": [
    {
      "@type": "personhood.worldId.verification",
      "issuer": "did:web:worldcoin.org",
      "requiredTrustTier": 2
    }
  ]
}

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; the venue verifies Alice's claims at the trust tier the venue requires.
• The venue presents its UM to Alice; Alice verifies the venue's claims at the trust tier Alice requires.
• A peer-to-peer exchange has both sides presenting and verifying simultaneously.

The effective trust tier for an interaction is the maximum of what either party demands. 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 (for example, one party cannot satisfy the other party'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.

6.5. Agent Delegation

The um:agentDelegation pointer type declares when a manifest subject has delegated session authority to an AI agent, bot, or proxy. This enables platforms to distinguish human-controlled sessions from delegated ones.

The um:agentDelegation pointer is placed in the manifest's pointers array.

6.5.1. Structure

Required fields:

• @type — MUST be "um:agentDelegation".
• delegateType — One of "ai-agent", "bot", "proxy", or "human-delegate".
• delegatedBy — DID of the delegating subject. MUST match the manifest subject.
• delegatedAt — ISO 8601 date-time when delegation was granted.
• expiresAt — ISO 8601 date-time when delegation expires. Platforms MUST reject expired delegations.

Optional fields:

• delegateId — DID or identifier of the delegate entity.
• scope — Array of capability strings the delegate may exercise.
• livenessEndpoint — URI for real-time liveness/delegation status queries.

{
  "@type": "um:agentDelegation",
  "delegateType": "ai-agent",
  "delegateId": "did:key:z6MkAgentBot",
  "delegatedBy": "did:key:z6MkAlice",
  "delegatedAt": "2026-04-01T10:00:00Z",
  "expiresAt": "2026-04-01T11:00:00Z",
  "scope": ["spatial.session", "social.messaging"]
}

6.5.2. Platform Guidance

Platforms SHOULD display delegation status to other users when present. Platforms MAY require human-only sessions for high-stakes actions (financial, governance). Platforms MAY query the livenessEndpoint for real-time status when available. Platforms MUST treat the delegation pointer as static for the manifest's TTL if livenessEndpoint is absent.

8.1. Normative References

The following project governance documents control how published Universal Manifest specification changes, deprecations, incidents, releases, and RFC intake are handled.

1. Breaking-Change Policy
2. Deprecation Policy
3. Incident Response and Rollback
4. Release Cadence
5. Spec Improvement Queue

8.2. Informative References

The following standards and prior art inform the identity binding, tiered trust model, and signature profile design in this specification.

1. NIST Special Publication 800-63-3: Digital Identity Guidelines (June 2017, updated 2024 supplement). Defines Identity Assurance Levels (IAL 1–3) and Authenticator Assurance Levels (AAL 1–3). The UM tiered trust model adapts NIST's tiered assurance framework to a local-first, portable document context.
2. Regulation (EU) 2024/1183: European Digital Identity Framework (eIDAS 2.0). Defines assurance levels (Low, Substantial, High) for electronic identification. Relevant for GDPR alignment and European adopters.
3. OpenID for Verifiable Presentations (OID4VP) — Draft specification, OpenID Foundation (2024). Defines VP presentation with audience binding and nonce parameters. The claims[].claimProof VP recommendations (domain + challenge) align with OID4VP patterns.
4. Presentation Exchange 2.0 — Decentralized Identity Foundation, v2.0.0 (2023). Defines how relying parties express credential/claim requirements. The requiredTrustTier field is a simplified analog.
5. Well Known DID Configuration — Decentralized Identity Foundation, v0.2 (2023). Prior art for cross-DID linking via /.well-known/did-configuration.json Domain Linkage Credentials. The identity.crossDidBinding convention is analogous but manifest-embedded rather than domain-hosted.
6. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — IETF (September 2023). Defines proof-of-possession binding for OAuth2 tokens. Directly analogous to the subject-signer binding problem addressed by the tiered trust model.
7. Verifiable Credential Status List v2021 — W3C CCG (2022); superseded by Bitstring Status List v1.0 (W3C, 2024). Privacy-preserving credential revocation and freshness checking. Target mechanism for claims[].claimProof credential status verification.
8. Verifiable Credentials Data Model v2.0 — W3C Recommendation (March 2025). Core data model for VCs and VPs. The claims[].claimProof field is inspired by but distinct from VCDM's evidence property (Section 9.2) — deliberately renamed to avoid semantic collision.
9. ISO/IEC 29115:2013 — Information technology — Security techniques — Entity authentication assurance framework (2013). International standard defining four entity authentication assurance levels (LoA 1–4). Additional prior art for the tiered trust model.
10. RFC 8785: JSON Canonicalization Scheme (JCS) — IETF (June 2020). Defines the deterministic JSON serialization used as the canonicalization step in the v0.2 signature profile.