Trust Tasks

A Trust Task is the unit of work in the OpenVTC ecosystem: a single, versioned JSON document that says who is asking whom to do what, signed by the asker, and carried over whichever transport the two parties share. Every exchange in the stack — granting a role, joining a community, issuing a credential, witnessing a relationship, backing up an agent, administering a mediator — is one of these documents, with a canonical https://trusttasks.org/spec/<family>/<task>/<MAJOR.MINOR> type URI. The framework is a Working Draft of the Trust Over IP Foundation’s Decentralized Trust Graph Working Group, and the Eucalyptus release (coordinated-releases, 2026-10-07) is the point at which the ecosystem finished betting on it: every call into the stack is a signed Trust Task, and the REST management surfaces that once stood beside it are gone.

Why

The problem Trust Tasks solve is stated plainly in the framework’s own introduction: parties cooperate over a network by agreeing on the shape of the work, and today that agreement is reached ad hoc — every onboarding flow and consent receipt described in a vendor schema, carried on a vendor protocol, validated by vendor code — producing “a combinatorial explosion of pairwise integrations.” This ecosystem felt the explosion in miniature. It has three carriers for the same operations: TSP (preferred), DIDComm and plain HTTPS. Without a shared document, “change this member’s role” would be three message formats with three authentication stories, and a feature added to one carrier would silently drift from the other two. A Trust Task is the task; the carrier is a detail chosen per peer from what the peer’s DID document advertises.

The second problem is schema drift. Before the Dogwood cycle the VTC’s handler responses had diverged from their published schemas in 33 places; a conformance sweep drove that to zero and the VTI began enforcing the framework at its dispatch spine (#1146, 2026-08-27). Generated types in four languages, built from the same payload.schema.json, are how the drift stays at zero.

The third is evidence. The VTI specification’s rationale puts it in one sentence: transport authentication says who opened this connection; a document proof says who authored this document, what it covers, and to whom it was addressed, and “only the second survives the message being stored, forwarded, replayed on another transport, or produced in evidence afterwards.” A signed Trust Task is a retainable record — “a named party asked a named party to do a named thing at a named instant” — which is what a trust graph needs when a role grant or a membership is later disputed. The VTI’s September design notes call the resulting entry point the signed door: an operation reachable only as a signed document, with any human step-up bound to that one operation’s payload digest rather than to a session (#1641 series, 2026-09-24 → 09-25).

What a Trust Task Is

One object, no envelope. The framework deliberately defines no wrapper. id (globally unique, UUIDv4 recommended), type (the type URI, whose trailing segment is the specification version), issuer and recipient (verifiable identifiers — DIDs here), issuedAt, optional expiresAt, optional threadId / parentThreadId for correlation, an optional ceremony member recording membership of a multi-task flow, the task-specific payload, and an optional proof. Everything but payload is framework-owned, so one framework schema validates the outside and one per-task schema validates the inside.

Three replies, told apart by type alone. Success is the same URI with #response; failure is trust-task-error with a standard code vocabulary (proofRequired, proofInvalid, malformedRequest, idConflict, expired…), retryable and retryAfter; a continuation is trust-task-next-step. A consumer must never infer the disposition from the payload. Each reply is itself a Trust Task, so one validation, signing and transport pipeline serves both directions.

Proof and sender binding. proof is a W3C Data Integrity proof with eddsa-jcs-2022 as the baseline every consumer must verify; its verificationMethod must resolve to key material controlled by the issuer and be authorized for the stated proofPurpose (tightened 2026-09-26, #637). In-band identity is authoritative and transport identity is a cross-check: a document whose issuer disagrees with the authenticated DIDComm or TSP sender is rejected. A proof without a recipient is rejected too — the audience-binding rule — unless the specification is explicitly a bearer one. The framework’s §9.1.1 forbids a transport binding from quietly waiving proofs: “silence is not permission.” That clause is why the VTI’s #1739 (2026-09-26) could require a sender-bound document proof on every DIDComm and TSP task — the DIDComm binding’s own text says a REQUIRED proof “is mandatory regardless of transport, because such specifications produce documents intended to be replayable past the original transport hop.”

Replay, freshness, idempotency. Consumer requirement 11 makes duplicate-execution protection normative for any consequential task (one that mutates state, discloses a secret or acts as the subject): once a document id is accepted, the same document arriving again must not have its effect twice, and a same-id-different-content arrival is an idConflict. Item 13 bounds that record with an acceptance window on issuedAt, which is why every consequential specification must require issuedAt. The Rust runtime ships these as ReplayGuard and FreshnessPolicy; the bindings absorb a mediator redelivery rather than run the task again (#276); the VTA’s idempotencyKey dedup sits on top for the lost-reply case. Since discovery 0.3 (2026-09-28) a responder advertises its acceptance window.

Consent and step-up are Trust Tasks too. Delegated Trust-Task Execution — the VTA’s approval ceremony — is three URIs (task-consent/request, decision, granted) with no REST endpoints of its own; the approver signs a decision echoing a challenge over a digest of the exact task URI and payload. auth/step-up and consent/approve-request are likewise registered tasks with proof REQUIRED. Credentials issued inside an exchange point back at it through taskContext, and multi-task flows are Trust Ceremonies (ADR 0001, 2026-08-09) evidenced by a trust-ceremony-receipt.

The Registry and the Task Force

The task force repository (trustoverip/dtgwg-trust-tasks-tf) is the registry: one folder per task at specs/<slug>/<MAJOR.MINOR>/ holding a spec.md with normative front matter (parties, proof requirement, side-effect and exposure class, error codes, target framework version) and a payload.schema.json. A new family arrives as a pull request with DCO sign-off, CODEOWNERS routes it to the namespace’s editors, and the build validates schemas, example documents and the category taxonomy before regenerating the site at trusttasks.org. The framework text itself has been generated from a canonical sibling repo, dtgwg-trust-tasks-spec, since 2026-09-21.

At Eucalyptus the registry holds 39 families and roughly 690 spec versions: the ecosystem’s own surfaces (vta/*, vtc/*, did-management/*, webvh/*, messaging/*, registry/*) and cross-cutting ones (acl/*, auth/*, keys/*, vault/*, credential-exchange/*, task-consent/*, backup/*, push/*…). The four families named in the Eucalyptus summary were authored in September alongside the features they describe: rooms/* (2026-09-02, data-rooms), persona/* (09-05, behind persona-credential), vetting/* (09-11, peer-identity-vetting) and git-ns/* (09-23, community-git-namespaces). Transport bindings have their own namespace, trusttasks.org/binding/<name>/<version>: https 0.3, didcomm 0.2, didcomm-v1 0.2 (for Aries-lineage agents such as keyring-bifold), tsp 0.1 (Rev 3 since 2026-09-16) and push 0.1. Framework revisions ran 0.1 (May), 0.2 (June, lowerCamelCase with a dual-accept window), 0.3.0 and 0.4.0 (August 8–9), 0.5.0 (08-26), 0.6.0 (09-21) and 0.7.0 (09-24).

The libraries are generated from the registry and released in lockstep: in Rust trust-tasks-rs with -proof, -https, -didcomm, -didcomm-v1, -tsp, -capability-client, -ceremony and a trust-tasks facade; in TypeScript @openvtc/trust-tasks and its proof, TSP and capability-client siblings; and, since 2026-09-16, Go (trust-tasks-go) and Dart (trust_tasks), each with the §7.2 consumer runtime and proof, HTTPS, DIDComm and TSP bindings.

How It Arrived

Milestone	Date	Framework / `trust-tasks-rs`
Repo created; registry bootstrapped with the framework, build pipeline and the ACL family; Rust reference and bindings the next day	2026-03-11; 05-16/17	0.1
Aspen — VTA adopts dual-accept Trust Task envelopes	2026-06-03	0.2 (06-06)
TSP binding; messaging family; Banyan	2026-06-22/23	0.2
VTI “canonical URI” migration — every wire operation on registry URIs, 66 private VTC bindings retired, REST routes marked superseded; Cypress	July → 2026-08-17	0.3/0.4; rs 0.5.0 (08-09), 0.9.0 (08-16)
Dogwood — “the wire became honest”: framework 0.5.0 at the dispatch spine, every producer signs, replay and freshness enforced	2026-08-27 → 08-30	0.5.0 (08-26); rs 0.17
Eucalyptus RC-0 — TSP Rev 3 envelope; Go and Dart; rooms, persona, vetting families	2026-09-16/17	0.6.0; rs 0.21.3
Eucalyptus — every call a signed, sender-bound Trust Task; REST management surfaces removed; git-ns	2026-10-07	0.7.0; rs 0.27.7

The last row is a four-week convergence across repos. In the VTI: proofs verified in the spine “where the bytes still exist” (#1501), the signed door for ACL grants, role changes, config and backup (#1702–#1724), a sender-bound proof on every DIDComm and TSP task (#1739), one Trust Task surface in vta-sdk (#1793), every VTC client call a signed Trust Task (#1840, 09-29), and the superseded REST routes retired, with pre-session authentication itself moving onto Trust Tasks (#1858, 10-01). The TDK mediator’s administration became Trust Tasks only (#850–#853, #901, 09-27); the DID hosting service deleted the REST management surface of both edge and control plane (#225, #238, 09-28); OpenVTC signs every request as the persona (#386). Between Dogwood and Eucalyptus the task force cut 96 trust-tasks-rs releases.

Who Speaks It

The VTA and VTC serve and consume them over all three carriers; the mediator answers its own management tasks; the DID hosting service and the trust registry (registry/*, TRQP) are reached by Trust Task only. On the client side: the openvtc TUI; the browser wallet, which signs every outbound task at the channel and uses vti-didcomm-js to treat the mediator as a Trust Task counterparty; the Keyring phone, whose @bifold/trust-tasks package carries eddsa-jcs-2022 proofs and the DIDComm v1 ~attach carriage, and whose witnessed VRC exchange is being recast onto vrc/relationships/* and witness/*; vgi-bridge in VGI, which relays git-ns/bridge events and jobs over TSP; and vta-mcp, where every AI tool call becomes a Trust Task classified by its declared risk class.

Relation to TSP, DIDComm and REST

The layers are distinct and the ecosystem is careful to keep them so. TSP and DIDComm provide confidentiality, sender authentication and (for TSP) routing privacy; a TSP relationship is admission; the ACL is authorization; the Trust Task is the statement of work and its evidence. Consumer requirement 10 says validation of identity or proof is never itself authorization. The three carriers are chosen in the order TSP > DIDComm > HTTPS from what the peer advertises, and on every one of them the same document with the same proof is required — a binding “MUST NOT weaken the document requirements on the basis of a property of the transport.” What remains of REST is the HTTPS binding: POST /trust-tasks carrying a signed document, not a route per verb.

Status and Open Questions

The framework is Working Draft 0.7.0, versioned on its own SemVer line and not yet a ToIP Approved Deliverable; a normative conformance suite is promised before it leaves draft, with the registry’s envelope schemas and generated runtimes as its basis. The specification itself notes the privacy cost of its own design — nearly every document names both parties in the clear and survives delivery — and treats identifier correlation as a live consideration, which is where correlation-scope and pairwise DIDs do their work. The VTI specification still records 49 tasks whose proof requirement was historically served behind a bearer JWT; closing that divergence is what the signed-door and REST-retirement work was for, and its remaining gaps are tracked in vtc-trust-task-proof-enforcement.md. Private, unpublished specifications are a conforming path (any authority but trusttasks.org, any slug but trust-task*), so the registry’s public families are a floor, not a boundary.

OpenVTC Wiki

Explorer