1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
//! One dependency line for the [Trust Tasks] framework.
//!
//! The framework ships as eight independently-versioned crates, because each
//! transport binding drags in a different (and heavy) dependency tree and you
//! should only pay for the one you use. That split is right for a build; it is
//! a tax at the front door. This crate is the front door: it re-exports the
//! others behind Cargo features so that getting started is one line and one
//! version.
//!
//! ```toml
//! trust-tasks = { version = "0.1", features = ["https", "proof-affinidi"] }
//! ```
//!
//! Everything here is a `pub use`. There are no wrapper types, no shims, and
//! nothing to keep in step: `trust_tasks::TrustTask` **is**
//! [`trust_tasks_rs::TrustTask`], and `trust_tasks::https::HttpsClient` **is**
//! `trust_tasks_https::HttpsClient`. Reaching for the underlying crate
//! directly later is a find-and-replace, not a migration.
//!
//! # Which crates do I need?
//!
//! (Module names are written out rather than linked: a link to a module behind a
//! Cargo feature you have not enabled is a broken link in *your* `cargo doc`.)
//!
//! | I want to… | feature | you get | underlying crate |
//! |---|---|---|---|
//! | model a Trust Task document, run the SPEC §7.2 consumer checks | *(always on)* | crate root: [`TrustTask`], [`consume_inbound`], [`specs`], [`RejectReason`] | `trust-tasks-rs` |
//! | send/receive over HTTPS (typed client + axum server) | `https` | `trust_tasks::https` | `trust-tasks-https` |
//! | send/receive over DIDComm v2.1 | `didcomm` | `trust_tasks::didcomm` | `trust-tasks-didcomm` |
//! | talk to Aries-lineage agents (DIDComm v1) | `didcomm-v1` | `trust_tasks::didcomm_v1` | `trust-tasks-didcomm-v1` |
//! | send/receive over the ToIP Trust Spanning Protocol | `tsp` | `trust_tasks::tsp` | `trust-tasks-tsp` |
//! | **sign** a document, or **verify** an inbound proof | `proof-affinidi` | `trust_tasks::proof` | `trust-tasks-proof` |
//! | validate payloads against their JSON Schema at runtime | `validate` | `trust_tasks::validate`, `trust_tasks::schema_index` | `trust-tasks-rs` |
//! | verify Trust Ceremony receipts and step digests | `ceremony` | `trust_tasks::ceremony` | `trust-tasks-ceremony` |
//! | build/parse `governance/capability/*` + `git-trust/*` wire documents | `capability-client` | `trust_tasks::capability_client` | `trust-tasks-capability-client` |
//! | bridge two bindings in one process | `all-transports` | all four transport modules | — |
//! | use `JwtBearerAuth` on the HTTPS server | `https-jwt` | `trust_tasks::https::JwtBearerAuth` | `trust-tasks-https` |
//!
//! Almost every real deployment wants **one transport plus `proof-affinidi`**:
//! a task whose specification declares `proof` REQUIRED (`acl/grant/0.1` is
//! one) cannot be produced or consumed without a signer and a verifier.
//!
//! # What this crate deliberately does not forward
//!
//! `trust-tasks-rs` carries **26 per-spec-family features** (`vault`, `acl`,
//! `keys`, …) so a size-sensitive build can compile only the families it
//! speaks. Those are **not** forwarded here. Only the `all-specs` umbrella is,
//! and it is on by default.
//!
//! That is a deliberate limit on what a facade is for. Twenty-six more feature
//! names in front of a newcomer is the problem this crate exists to remove, and
//! forwarding them would not even work reliably: Cargo unifies features across
//! the whole dependency graph, so trimming spec families only pays off when
//! nothing else in the graph asks for them. **If you are trimming spec
//! families, depend on `trust-tasks-rs` directly and skip this crate.** That is
//! a supported answer, not a workaround — this crate is a convenience for
//! getting started, and you have outgrown it.
//!
//! The same applies to *subtracting* a transport crate's own defaults. Cargo
//! features are additive, so nothing here can turn `trust-tasks-https`'s
//! `server` off or close `trust-tasks-didcomm-v1`'s `legacy-basic-message`
//! gate. Those need `default-features = false` on the crate itself.
//!
//! # A first round trip
//!
//! See [`GETTING-STARTED.md`] at the repo root for a signed `acl/grant`
//! exchange with both ends written out, the TypeScript equivalent, and the
//! four traps that reliably cost an afternoon. The Rust in that document is
//! extracted from `examples/acl_grant_roundtrip.rs` in this crate and a test
//! fails if the two drift, so it is code that compiles and runs rather than
//! code that once did.
//!
//! ```sh
//! cargo run -p trust-tasks --features https,proof-affinidi \
//! --example acl_grant_roundtrip
//! ```
//!
//! [Trust Tasks]: https://trusttasks.org/
//! [`GETTING-STARTED.md`]: https://github.com/trustoverip/dtgwg-trust-tasks-tf/blob/main/GETTING-STARTED.md
//!
//! # Versioning
//!
//! This crate exposes `trust-tasks-rs` types in its own public API, so a
//! breaking change there breaks this crate's callers even when nothing here
//! changes. `cargo-semver-checks` cannot catch that: it compares each crate's
//! rustdoc against that crate's own published baseline, and does not track
//! type identity across dependency versions. The crates that share
//! `trust-tasks-rs` in their public API are therefore released as one
//! compatibility unit with a single shared version — see `version_group` in
//! `release-plz.toml`.
// The core crate lands at the root, flattened: `trust_tasks::TrustTask`,
// `trust_tasks::specs::…`, `trust_tasks::consume_inbound`. A glob rather than
// an enumerated list on purpose — an item added to `trust-tasks-rs` should
// appear here without anyone remembering to add it, which is the failure mode
// a hand-maintained re-export list has.
pub use *;
/// The core crate itself, under its own name.
///
/// Useful when you want to be explicit about where a type comes from, or need
/// to name the crate in a path that a glob re-export cannot express.
pub use trust_tasks_rs as rs;
/// HTTPS transport binding — typed client, axum-based server, bearer-token
/// identity. Re-export of [`trust_tasks_https`].
pub use trust_tasks_https as https;
/// DIDComm v2.1 transport binding, built on `affinidi-messaging-didcomm`.
/// Re-export of [`trust_tasks_didcomm`].
pub use trust_tasks_didcomm as didcomm;
/// DIDComm **v1** transport binding, for Aries-lineage agents that speak v1
/// only. Re-export of [`trust_tasks_didcomm_v1`].
pub use trust_tasks_didcomm_v1 as didcomm_v1;
/// ToIP Trust Spanning Protocol transport binding, built on `affinidi-tsp`.
/// Re-export of [`trust_tasks_tsp`].
pub use trust_tasks_tsp as tsp;
/// Signing and proof verification. `proof::ProofExt` adds `.sign()` to a
/// [`TrustTask`]; `proof::affinidi::Verifier` is what a server hands to
/// `with_verifier`. Re-export of [`trust_tasks_proof`].
pub use trust_tasks_proof as proof;
/// Trust Ceremony verification — salted step digests, receipt checking,
/// completion rules. Re-export of [`trust_tasks_ceremony`].
///
/// Note this crate does **not** depend on `trust-tasks-rs`; it is a standalone
/// verifier over a ceremony definition.
pub use trust_tasks_ceremony as ceremony;
/// Wire helpers for the capability families — `governance/capability/*` and
/// `git-trust/*` document builders, envelope parsing, reply classification.
/// Re-export of [`trust_tasks_capability_client`].
pub use trust_tasks_capability_client as capability_client;