v0.2: Signatures and Identity Binding

Universal Manifest v0.2 answered the question v0.1 left open: how does a system receiving a manifest know it is authentic, current, and unrevoked?

Signatures became mandatory

v0.1 included an optional proof slot. v0.2 made it non-optional. Every conformant manifest must carry a cryptographic signature. The baseline is JCS (JSON Canonicalization Scheme) with Ed25519, chosen for broad library support and compact key size.

Signature verification runs at the Verify stage of the evaluation sequence. If the signature fails, the evaluation stops. There is no “proceed anyway” option for conformant evaluators.

Four trust tiers

Not all claims carry the same weight. v0.2 introduced a tiered model:

1. Self-asserted. The subject makes a claim about themselves. No external validation.
2. Attested. A third party vouches for the claim with their own signature.
3. Cryptographic binding. The claim is linked to a verifiable credential or proof of possession.
4. Multi-party ceremony. Multiple independent parties must co-sign, making collusion expensive.

Each facet in the manifest carries its trust tier. An evaluator can see at a glance whether a claim is self-asserted or independently attested, and apply policy accordingly.

Agent delegation

AI agents, bots, and proxies can now carry delegated authority with explicit scope and expiry. A delegation entry names the delegating entity, the delegated agent, the permissions granted, and the time window. When the window closes, the delegation is void without any revocation ceremony.

Revocation-aware verification

v0.2 added revocation status as a mandatory check. A manifest that was valid yesterday may be revoked today. Evaluators query revocation registries during the Verify stage. A revoked manifest fails evaluation cleanly.

What this meant

Manifests became verifiable documents. An evaluator can check that a manifest is authentic (signature holds), current (not expired), unrevoked (registry confirms), and appropriately trusted (tier matches policy). The foundation was set for v0.3 to define what evaluators must do with this verified information.

Read the v0.2 specification for the full signature scheme and trust tier definitions.