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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
/// Issued-credential lifecycle (`spec/vta/credentials/{issue,revoke}/0.1`) —
/// mint + revoke a VTA-signed W3C VC addressed to a holder DID.
/// Member-side membership-credential exchange (`members/*`) — the member → VTC
/// reciprocal VMC and the VTC's request for it.
/// Per-context key/value store for AI-agent memory
/// (`spec/vta/memory/{put,list,delete}/0.1`).
/// Versioned, namespaced application state
/// (`spec/vta/app-state/{get,put,list,delete,get-many,put-many}/1.0`) — the
/// third store, beside the vault and agent memory, for JSON an application owns
/// and the VTA does not interpret.
/// Passkey-based login flow (`vta/auth/passkey-login-{start,finish}/1.0`).
/// Runtime Policy Decision Point management (`policy/*`) — where the
/// declarative approvals model is read and written.
/// Peer identity vetting before joining a community (`spec/vetting/*`,
/// `spec/vtc/vetting/*`) — serde shapes only; signing and verification are in
/// `crate::vetting`.
// Standard DIDComm protocol types used across VTA/VTC services
pub const PROBLEM_REPORT_TYPE: &str = "https://didcomm.org/report-problem/2.0/problem-report";
pub const TRUST_PING_TYPE: &str = "https://didcomm.org/trust-ping/2.0/ping";
pub const MESSAGE_PICKUP_STATUS_TYPE: &str = "https://didcomm.org/messagepickup/3.0/status";
/// Problem-report `code` values emitted by VTA/VTC services. Kept in sync with
/// the `affinidi_messaging_didcomm_service::problem_report::codes` taxonomy so
/// the SDK can classify errors without depending on the server-side crate.
/// Machine-readable `details.reason` values the VTA puts on a Trust-Task
/// rejection so the client can recover the outcome the server actually had.
///
/// # Why this exists
///
/// The Trust-Task framework defines no `notFound` / `conflict` / `gone`
/// standard code, so all three ride out under `taskFailed`
/// ([`RejectReason::TaskFailed`]). The code alone therefore cannot distinguish
/// "the row you asked for is absent" — routinely a *normal* state a caller
/// handles — from "this operation genuinely failed". Collapsing them loses
/// information that both the REST path (HTTP 404 / 409 / 410, see
/// [`VtaError::from_http`]) and the DIDComm protocol-message path
/// ([`problem_report_codes`], see [`VtaError::from_problem_report`]) preserve,
/// leaving the Trust-Task transport the only one that hands the caller an
/// opaque string.
///
/// The concrete failure this was written for: a VTA that has never had an
/// approval rule has no `approvals` policy row, which is the shipping default.
/// `pnm approvals list` reads that row through `policy/get/0.1` and is written
/// to treat a missing one as an empty model — but the `NotFound` never arrived
/// as `NotFound`, so *every* `pnm approvals` subcommand failed on a fresh VTA,
/// including the `require` that would have created the first rule.
///
/// The channel is the one the consent gate already established: `code` is
/// `taskFailed` for everything, so a consumer keys on a stable `details.reason`
/// instead.
///
/// [`RejectReason::TaskFailed`]: https://docs.rs/trust-tasks-rs
/// [`VtaError::from_http`]: crate::error::VtaError::from_http
/// [`VtaError::from_problem_report`]: crate::error::VtaError::from_problem_report
/// Machine-readable `details` members the VTA puts on an
/// `unsupportedType` / `unsupportedVersion` rejection.
///
/// # Why this exists
///
/// The framework carries the rejected Type URI only inside the human-readable
/// `message` (`unsupported type: <uri>`), and carries what the responder
/// *does* serve nowhere at all. So the one rejection whose fix is "upgrade
/// something" gave a client no way to say **which** thing without slicing a
/// sentence — and the version in that sentence is the whole diagnosis: an
/// older version named means the client is behind, a newer one means the
/// responder is.
///
/// Sibling of [`trust_task_reject_reasons`] and here for the same reason: the
/// service writes these keys and the SDK reads them, so a second spelling in
/// either place is a wire contract that drifts silently.
///
/// Absent from an older responder — a consumer must treat a missing
/// [`SERVED_VERSIONS`] as "unknown", never as "the family does not exist".
/// Extract code and comment from a problem-report message body.