For each of the eight ceremonies in the interactive pipeline, this page lists every Trust Task it emits or consumes, and resolves each Trust Task slug against the public registry at trustoverip/dtgwg-trust-tasks-tf/specs (the source for what trusttasks.org publishes). Two slug families are already in the registry; the rest are proposed and would need a DTGWG specification before they're usable across ecosystems.
| Slug · version | What it does | Where it's used here | Registry status |
|---|---|---|---|
| acl/grant/0.1 | An ACL maintainer grants a subject a role on a resource. Payload requires an entry (an AclEntry object) and an optional reason; the success response carries the canonical AclEntry the maintainer now holds.
Issuer: ACL maintainer · Recipient: subject (or proxy thereof) |
founding-complete consumed (count_acl_grants ≥ 5 gates the COMPLETE route) founding-vmc consumed (subject_has_acl_grant verifies a per-founder grant) | registered trust-tasks-tf/specs/acl/grant/0.1/payload.schema.json spec.md (8.4 kB) |
| ceremony/close-request/0.1 | The convener of a thread requests that the thread be closed without reaching ceremony/complete. Distinct from complete: signals "we're giving up", not "we succeeded". Triggers the thread-close meta-policy.
Issuer: thread convener · Recipient: each participant |
thread-close consumed (convener_initiated_close triggers the INCOMPLETE route) | proposed No spec yet · would live at specs/ceremony/close-request/0.1/
|
| ceremony/complete/0.1 | A thread's terminal "we succeeded" artifact. The payload enumerates every constituent document in the thread (proposals, responses, vouches, ACL grants, agreed bylaws/scopes). Downstream issuance steps reference its id in their ceremonyEvidence field.
Issuer: thread convener (Thread A) or qualifying authority (Thread B) · Recipient: each participant |
founding-complete emitted (COMPLETE / COMPLETE_WITH_EXCEPTIONS) admission-approve emitted (COMPLETE / COMPLETE_WITH_EXCEPTIONS) founding-vmc consumed admission-apply consumed (constituting_evidence_verified) admission-vmc consumed thread-close consumed (presence shorts P3 ABANDONED) | proposed Discussed in dtgwg-trust-tasks-tf #28; no spec submitted yet |
| ceremony/propose/0.1 + #request, #response |
A ceremony convener invites a counterparty (or fans out to multiple counterparties via separate bilateral documents linked by threadId) into a defined ceremony. The proposal payload declares ceremony type (Connecting / Qualifying), required completion signers, and referenced evidence. The #response fragment is the recipient's reply with the decision field set to "accept", "decline", or "counter".
Issuer: convener (request) or recipient (response) · Recipient: counterparty (request) or convener (response) |
founding-propose emitted #response (decision=accept) admission-apply emitted #response (decision=accept) founding-complete consumed (count_founder_acceptances) admission-approve consumed (application_referenced) thread-close consumed (decline-coded #response triggers REFUSED) | proposed The 0.1 walkthrough in discussion #28 sketches the payload shape; no formal spec yet |
| guarantor/vouch/0.1 | An existing member of a Verifiable Trust Community vouches for an applicant to that community. Payload binds the applicant VID, the guarantor's own membership credential id (proving eligibility), and the application's threadId. Carries optional reasoning and scope.
Issuer: existing community member · Recipient: the community admission authority |
admission-vouch emitted (the gate's whole job) admission-apply consumed (inline_vouches optimization) admission-approve consumed (count_distinct_vouches ≥ 2 gate) | proposed Discussed in discussion #28; no spec submitted yet |
| trust-task-discovery/0.1 | Bilateral capability discovery — two parties confirm they speak the same Trust Task vocabulary before launching into a multi-step exchange. Each party advertises the slug patterns it understands; the response lists supported patterns. Issuer: either party · Recipient: either party | A0 / B0 precondition step in both threads (mentioned in examples/README, not modelled as a separate policy ceremony since it's purely a vocabulary check) | framework trust-tasks-tf/specs/trust-task-discovery/ |
| trust-task-error | Framework-level error response. Payload carries an error_code identifying the failure class (e.g. incompatible_terms, verification_failed, rate_limited) and a human-readable message. Individual Trust Task specs MAY extend with task-specific codes.
Issuer: party rejecting / failing on a prior document · Recipient: that prior document's issuer |
founding-propose emitted (incompatible_terms, too_many_counters) founding-complete emitted (thread_aborted on FAILED) admission-apply emitted (bylaws_incompatible, not_constituted, too_many_counters) admission-approve emitted (community_consent_denied) thread-close consumed (refusal- vs failure-coded errors split REFUSED from FAILED) | framework trust-tasks-tf/specs/trust-task-error/ |
| vmc/issue/0.1 | Issues a Verifiable Membership Credential. The payload references the ceremony/complete document's id in a ceremonyEvidence field so a downstream verifier can trace the membership back to the ceremony that produced it. Distinct from the VMC itself (which is a credential, not a Trust Task).
Issuer: a VTC's authority · Recipient: the new member |
founding-vmc emitted (C → founder) admission-vmc emitted (TCF → C) | proposed Discussed in discussion #28; no spec submitted yet |
The framework reserves #request and #response as the only valid fragments
on a Type URI: "an individual Trust Task specification MUST NOT
assign other fragment meanings to its type URI." Our earlier ceremony/propose/0.1#response (accept)
was non-conformant — the (accept) suffix is invalid. Fixed: we emit the
clean ceremony/propose/0.1#response and carry decision: "accept" as a payload
field instead.
Type URIs follow https://trusttasks.org/spec/<slug>/<MAJOR.MINOR>. Slugs whose
first segment is trust-task or begins with trust-task- are framework-reserved;
we use those slugs correctly (trust-task-error, trust-task-discovery).
A producer/consumer pair MAY use Trust Task specifications they define under their own HTTPS
authority, never publishing under trusttasks.org. The visual guide's manifestNs
prose currently claims https://trusttasks.org/spec/ceremony/...,
vmc/..., guarantor/... — namespaces that don't exist in the public
registry (the proposed rows above). Strictly read, §6.5 reserves the
trusttasks.org authority for the public registry; a more conformant path would be to
either submit these slugs to the DTGWG or to relocate them under an authority we control (e.g.
https://openvtc.org/trust-tasks/<slug>/<version>) and treat them as private
specifications until the DTGWG accepts them. This is a documentation finding, not a code bug.
Per-Type-URI schemas describe only the payload; the outer document structure
(id, threadId, type, issuer,
recipient, issuedAt, payload, proof) is governed by
the framework schema at https://trusttasks.org/spec/trust-task/<MAJOR.MINOR>.
Anything we put in allow.with beyond the emits slug (decision,
terminal_state, exceptions, obligations) is host-side
metadata that drives what the host packs into the emitted Trust Task's payload — it is not part of
any Trust Task schema itself.