Roadmap

v0.3 · current

Receiver contract and trust tiers.

v0.3 defines the receiver-behavior contract: what every conformant receiver does when a manifest arrives, in what order, and what it records. A conformance suite exercises every behavior against real fixtures.

The receiver pipeline

Every conformant receiver runs the same pipeline:

1. Arrive. The manifest is received and parsed. Structure and resource limits are checked.
2. Verify. The signature is checked against the JCS-canonicalized payload. Revocation status is resolved if a status endpoint is available. Freshness is confirmed; expired manifests are rejected.
3. Project. Only the facets relevant to this receiver are extracted. Projection is sender-controlled: the receiver gets what was intended, not everything with irrelevant parts stripped after the fact.
4. Evaluate consent. Per-facet consent records are checked: scope, purpose, expiry, withdrawal status. Encrypted facets are acknowledged as present but not read.
5. Compose result. Four possible outcomes: accepted, accepted-with-warnings, accepted-partial, rejected. Each is machine-readable and structured.
6. Write receipt. An honest record of what the receiver actually did: what it checked, what it accepted, what it refused, and what was opaque. The receipt is verifiable.

The four pillars

The receiver contract is built on four properties that hold across every exchange:

• Projection. Each receiver sees only what the sender intended. This is architectural scoping, not post-hoc filtering. The irrelevant parts never arrive.
• Consent. Per-facet, per-purpose, with scope, expiry, and withdrawal. Consent travels with the data and is evaluated at the point of use.
• Opacity. Encrypted facets are present in the manifest and acknowledged by the receiver, but their contents are unreadable. The receiver cannot pretend they don't exist. The receipt records them as opaque.
• Authenticity. Signatures, revocation checks, and freshness are verified before any other behavior. If verification fails, the sequence stops.

Trust tiers and delegation

The receiver contract carries the identity binding framework into concrete behavior. A receiver can require the tier that matches the exchange: Tier 0 for signed self-assertion, Tier 1 for attested claims, Tier 2 for cryptographic binding with zero-knowledge or multi-signature proof, and Tier 3 for multi-party ceremony in the highest-stakes contexts. Tiers 0 and 1 are usable in the current contract. Tiers 2 and 3 are specified so unsupported requirements can be rejected cleanly until their profiles advance.

Agent delegation lets AI agents, bots, and proxies carry scoped authority with expiry and optional liveness verification. A receiver can distinguish a manifest presented by a person from a delegated session and record that distinction in the receipt.

Bilateral exchange

Trust verification is two-directional. Both parties present manifests to each other. A hotel checks your identity; you check the hotel's authority. The effective trust tier is the maximum of both parties' requirements.

Live implementations

The standard is already being implemented. peers.social is an open-source, self-sovereign identity system built local-first. Users manage their social graph and everything they publish through a Universal Manifest at the core. It's built on the open-source projects at peermesh.org. These are live integrations, not roadmap items.

OMA3 is reviewing the specification. Adjacent standards communities are engaged through the project's lineage in working groups.

What is being built now

• Envelope validation tightening. Implementer feedback from v0.3 deployments is driving stricter validation rules and resolving ambiguity reports.
• Conformance suite expansion. Adding coverage for promoted cryptographic profiles, edge-case projection scenarios, and multi-facet manifests with mixed visibility states.
• External cryptographic profile review. Profiles promoted beyond baseline are being reviewed by domain experts. Profiles that don't pass review are formally deferred with a public reason.
• Official GitHub repositories. Clean, focused examples of envelope construction, projection, receiver-behavior pipelines, conformance fixtures, and integration patterns. The goal: an implementer reads a use case on the site, clicks through to the repo, and has running code within the hour.
• Pilot programs. peers.social integration (consent and projection in a live social context), app-store demonstration (manifest handshake on real devices under mobile OS constraints), and open-source hardware implementation (smart glasses running the consent handshake under latency and power constraints).

v0.3 is usable today for pilots, internal tools, research integrations, and trusted-network deployments. The envelope structure, receiver-behavior contract, conformance suite, and baseline cryptographic profile are stable to build on. The contract may still change between versions; that's the tradeoff of building at this stage.

Spec v0.3 →

v0.4 · next

Production-candidate.

v0.4 is the production-candidate milestone. It incorporates refinements from v0.3 deployment feedback and closes the evidence gates that separate early-adopter use from production commitment.

The specification at v0.4 tightens the receiver-behavior contract based on what implementers found in practice: stricter validation, resolved ambiguities, and removed optional surface area that deployment evidence did not justify.

Production-candidate is also an evidence bar. The project claims it only when all of the following have been demonstrated:

• External reader validation. Implementers outside the project have read the spec, run the fixtures, and reported where the contract is clear and where it is ambiguous.
• Independent implementations. At least two implementations, built independently, pass the conformance suite.
• Reviewed cryptographic profiles. Profiles promoted beyond baseline have been reviewed by external cryptographers or formally deferred with a published reason.
• Production deployment. At least one non-trivial deployment has run for 90 or more days, long enough to surface operational issues that test suites miss.
• Adopter cohort. Four or more organizations have participated in implementation or evaluation feedback. Passive interest does not count.
• Versioning policy published. Production adopters know what can break, what cannot, and how major-version transitions will be handled.

No single gate is sufficient. All six close together or the claim is not made.

Wait for v0.4 if your deployment requires independent implementation evidence, reviewed promoted profiles, a stable versioning guarantee, and a production deployment track record.

v0.4 preview →

v0.5 · planned

Advanced protocols.

Protocol additions earned by deployment evidence, not planned by calendar. Each advances when real-world use justifies the added complexity.

Zero-knowledge proofs. A ZK proof profile enabling Tier 2 identity binding: cryptographic proof that the same entity controls multiple identifiers without revealing which identifiers are linked. This is what makes privacy-preserving Sybil resistance possible: proving you are a unique participant without exposing your identity across contexts. The profile advances when wallet and credential ecosystems produce implementations that can be tested against the conformance suite.

Higher-assurance ceremonies. Stronger ceremony tiers and multi-signature support for deployments where Tier 1 attestation is not sufficient but full Tier 3 multi-party ceremony is too heavy. Includes signature-purpose taxonomy so receivers can distinguish between different signer roles.

Post-quantum signatures. A post-quantum signature profile. The current baseline (Ed25519) is not quantum-resistant. A post-quantum profile will be promoted when wallet and credential ecosystems publish post-quantum keys at usable scale. This is preparation, not panic. The timeline is years, but the architecture must accommodate it.

Key and identifier lifecycle. Formal rotation policy for manifest identifiers, subject identifiers, and signing keys in long-lived deployments. Includes compromise-response rules (24-hour target for high-volume issuers) and rotation cadence guidance.

Trust anchor discovery. A shared protocol for discovering and evaluating trust anchors across implementations. Currently trust anchors are deployment-specific; this makes them discoverable.

Federation. Resolver coordination for status checks, cache invalidation, and availability across multiple resolver operators. Moves the spec from single-resolver deployments to federated infrastructure.

v0.5 features advance individually as evidence justifies them. An adopter interested in ZK proofs does not need to wait for federation, and vice versa.

Advancement condition: implementation evidence for each protocol profile.