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
//! DIDComm message types for runtime service management
//! (`pnm services rest …` / `pnm services didcomm …`).
//!
//! Spec: `docs/05-design-notes/runtime-service-management.md`.
//!
//! Naming follows the `firstperson.network/protocols/<name>/1.0`
//! convention used elsewhere in this crate. Two protocols:
//!
//! - **services-management/1.0** — REST + DIDComm enable / update /
//! disable / rollback / list. (`didcomm-enable` is REST-only by
//! nature, since DIDComm isn't running yet at first-enable; the
//! `enable-not-available-via-didcomm` placeholder surfaces this
//! to callers who try.)
//! - **mediator-management/1.0** — drain-cancel / report (the
//! per-mediator drain set + telemetry surface, which is DIDComm-
//! only by definition since REST has no in-flight state).
//!
//! For each request type, a matching `*-result` type exists on the
//! response side. The body shapes mirror the REST request/response
//! types in [`crate::protocol`].
pub const SERVICES_PROTOCOL_BASE: &str =
"https://firstperson.network/protocols/services-management/1.0";
pub const MEDIATOR_PROTOCOL_BASE: &str =
"https://firstperson.network/protocols/mediator-management/1.0";
// ── services-management ─────────────────────────────────────────────
pub const DISABLE_DIDCOMM: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-disable";
pub const DISABLE_DIDCOMM_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-disable-result";
// REST-side service management. Spec:
// `docs/05-design-notes/runtime-service-management.md` §3.4.
// All three are reachable over DIDComm — REST is always running
// (per spec §3.2 at-least-one-service invariant), so a request
// adding/updating/removing the REST advertisement can travel over
// DIDComm without hitting the same chicken-and-egg problem as
// `enable_didcomm` (which can't be invoked over a transport that
// isn't running yet).
pub const ENABLE_REST: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-enable";
pub const ENABLE_REST_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-enable-result";
pub const UPDATE_REST: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-update";
pub const UPDATE_REST_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-update-result";
pub const DISABLE_REST: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-disable";
pub const DISABLE_REST_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-disable-result";
// Fail-forward rollback ops (T3.x). Read the per-kind snapshot
// and dispatch into the equivalent forward operation. Reachable
// over both transports — REST is always running per spec §3.2,
// and the dispatched forward ops handle the chicken-and-egg
// concerns themselves (e.g. enable_didcomm is REST-only by
// nature; rollback into it falls back to that constraint).
pub const ROLLBACK_REST: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-rollback";
pub const ROLLBACK_REST_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/rest-rollback-result";
pub const ROLLBACK_DIDCOMM: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-rollback";
pub const ROLLBACK_DIDCOMM_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-rollback-result";
// Read-only inspection (T4.2). Auth: super-admin. The result
// payload uses the SDK's `ServicesListResponse` shape — one
// entry per kind, canonical DIDComm-before-REST order.
pub const LIST_SERVICES: &str =
"https://firstperson.network/protocols/services-management/1.0/list";
pub const LIST_SERVICES_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/list-result";
pub const LIST_DRAIN: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-drain-list";
pub const LIST_DRAIN_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-drain-list-result";
// ── services-management (DIDComm side, continued) ───────────────────
// T2.3 rename — was MIGRATE_MEDIATOR / mediator-management/1.0/migrate.
// The operation isn't really "migrating the mediator," it's updating
// which mediator the DIDComm service is using (spec §3.4). Renamed
// end-to-end (URL, Rust constant, request / response types, handler
// functions, telemetry kind) to align with the unified
// `services {kind} {verb}` surface.
pub const UPDATE_DIDCOMM: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-update";
pub const UPDATE_DIDCOMM_RESULT: &str =
"https://firstperson.network/protocols/services-management/1.0/didcomm-update-result";
// ── mediator-management (drain bookkeeping only) ────────────────────
//
// These remain under mediator-management/ — they operate on the
// drain set, not the active mediator advertisement, so the original
// name is still accurate.
pub const DRAIN_CANCEL: &str =
"https://firstperson.network/protocols/mediator-management/1.0/drain-cancel";
pub const DRAIN_CANCEL_RESULT: &str =
"https://firstperson.network/protocols/mediator-management/1.0/drain-cancel-result";
pub const MEDIATOR_REPORT: &str =
"https://firstperson.network/protocols/mediator-management/1.0/report";
pub const MEDIATOR_REPORT_RESULT: &str =
"https://firstperson.network/protocols/mediator-management/1.0/report-result";