Skip to content
Universal Manifest

Specification v0.2 (draft)

v0.2 exists to harden interoperability around integrity (signing + verification) while keeping v0.1’s adoption-friendly “state capsule” shape.

Core idea:

  • v0.1 lets implementations include a signature placeholder envelope.
  • v0.2 defines a portable, deterministic signature profile so two independent implementations can sign/verify the same payload the same way.

Not either-or: profiles are additive

Section titled “Not either-or: profiles are additive”

This is not a permanent either-or decision.

We can:

  • start with a pragmatic, easiest-to-adopt profile (JCS + Ed25519), and
  • add a Data Integrity profile later if/when we need “sign the RDF meaning” semantics.

Consumers verify the profiles they support and safely ignore unknown profiles.

v0.2 signature profile (draft)

Section titled “v0.2 signature profile (draft)”

v0.2 baseline:

  • Canonicalization: JCS (RFC 8785)
  • Signature: Ed25519
  • Signature encoding: base64url

Rationale:

  • broadly implementable across languages
  • deterministic signing input without requiring JSON-LD/RDF tooling
  • aligns with Universal Manifest’s “portable state capsule” contract

Signature envelope (shape)

Section titled “Signature envelope (shape)”

v0.2 uses a signature object with explicit fields that allow verifiers to know exactly what to do.

Required intent (draft):

  • signature.algorithm MUST be "Ed25519"
  • signature.canonicalization MUST be "JCS-RFC8785"
  • signature.value MUST be base64url signature bytes

Verification material is referenced (draft options):

  • signature.publicKeySpkiB64 MAY embed an SPKI DER public key (base64), or
  • signature.keyRef MAY point to external verification material (e.g., DID URL)

Signing input

Section titled “Signing input”

To sign or verify:

  1. Create a copy of the manifest with signature removed.
  2. Canonicalize the remaining JSON object using JCS (RFC 8785).
  3. Sign/verify those canonical bytes with Ed25519.

If verification fails, the manifest MUST be rejected for use (it may still be retained for debugging).

Fixtures (draft)

Section titled “Fixtures (draft)”

v0.2 includes a minimal signed fixture plus invalid fixtures:

  • valid: /harness/fixtures/v0.2/minimal-signed-manifest.jsonld
  • invalid: /harness/fixtures/v0.2/invalid/missing-signature.jsonld
  • invalid: /harness/fixtures/v0.2/invalid/invalid-signature.jsonld

Published artifacts (draft)

Section titled “Published artifacts (draft)”

Draft artifacts are expected to resolve over HTTPS:

  • JSON-LD context: /ns/universal-manifest/v0.2/schema.jsonld
  • JSON Schema: /ns/universal-manifest/v0.2/schema.json

On the canonical standards host, that means:

  • https://universalmanifest.net/ns/universal-manifest/v0.2/schema.jsonld
  • https://universalmanifest.net/ns/universal-manifest/v0.2/schema.json

Next

Section titled “Next”
  • Verification obligations + invalid cases: Conformance → v0.2
  • Live resolver contract behavior: Conformance → Resolver