vta_sdk/lib.rs
1//! # `vta-sdk` — SDK for Verifiable Trust Agents
2//!
3//! A Verifiable Trust Agent (VTA) holds a BIP-39 master seed, derives keys
4//! via BIP-32, and exposes a REST + DIDComm API to operators and integrations.
5//! This crate is the typed client that lets a Rust service:
6//!
7//! * authenticate against a VTA over REST or DIDComm,
8//! * call into every management surface (keys, contexts, ACL, DID templates,
9//! audit, backup, WebVH),
10//! * receive secret-bearing bundles via the `sealed_transfer` envelope
11//! (HPKE + ASCII armor + producer assertion),
12//! * provision integrations (mediators, WebVH hosts, app identities) end-to-end
13//! via VP-framed bootstrap requests + VC-issued admin authorization.
14//!
15//! ## Quick start
16//!
17//! Two-step pattern: import a credential, then call the typed client.
18//!
19//! ```rust,no_run,ignore
20//! # async fn run() -> Result<(), Box<dyn std::error::Error>> {
21//! use vta_sdk::client::VtaClient;
22//! use vta_sdk::credentials::CredentialBundle;
23//!
24//! // The credential is what the operator hands you (a base64 blob the VTA
25//! // setup wizard printed, or the result of `pnm bootstrap connect`).
26//! let credential = CredentialBundle::decode("<base64-credential>")?;
27//! let client = VtaClient::from_credential(&credential, None).await?;
28//!
29//! // Typed REST surface — `?` returns a `VtaError` with HTTP-aware variants
30//! // (Conflict, Gone, Forbidden, NotFound, …) so callers can surface targeted
31//! // operator errors instead of stringifying generic failures.
32//! let contexts = client.list_contexts().await?;
33//! for ctx in contexts {
34//! println!("{} — {}", ctx.id, ctx.label);
35//! }
36//! # Ok(()) }
37//! ```
38//!
39//! ## Sealed-transfer round-trip
40//!
41//! See [`sealed_transfer`] for the HPKE envelope used to move credentials,
42//! mediator secrets, and DID-secrets bundles between operator hosts:
43//!
44//! ```rust,ignore
45//! use vta_sdk::sealed_transfer::{seal_payload, open_bundle, generate_keypair, ...};
46//! ```
47//!
48//! ## Feature flags
49//!
50//! The crate is split into opt-in features so a thin types-only consumer
51//! doesn't pay the dependency cost of the full client. Pick the smallest
52//! set that compiles for your use case.
53//!
54//! | Feature | What it enables |
55//! |---|---|
56//! | `client` | Synchronous REST [`client::VtaClient`] (depends on reqwest, ed25519) |
57//! | `didcomm` | DIDComm transport types and message helpers |
58//! | `session` | Session storage + auth state machine. Needs a persistence backend (`keyring` or `config-session`). |
59//! | `keyring` | OS-native session storage via `keyring-core` (macOS Keychain / Windows Credential Manager / Linux Secret Service) |
60//! | `config-session` | Plaintext on-disk session storage (dev / non-sensitive contexts only) |
61//! | `azure-secrets` | Azure Key Vault session backend (requires `azure-secrets` env). Mutually exclusive with `keyring` at the SDK level. |
62//! | `sealed-transfer` | HPKE-sealed bundle envelope (seal, open, armor, producer assertions) |
63//! | `provision-integration` | VP-framed bootstrap requests + VC-issued admin authorization |
64//! | `provision-client` | Higher-level orchestration over `provision-integration` (TUI-agnostic) |
65//! | `attest-verify` | Full AWS Nitro attestation verification (cert chain to AWS root) |
66//! | `vp` | DCQL credential selection + holder-bound OID4VP `vp_token` assembly ([`vp`]) |
67//! | `integration` | Pull-bundle service-startup pattern (combines `client` + `session`) |
68//! | `test-support` | In-memory mocks (`SessionBackend`, fixtures) for downstream tests |
69//!
70//! ## Module map
71//!
72//! * [`client`] — synchronous REST client + typed request/response shapes
73//! * `agent_session` (feature `session`) — high-level personal-AI-agent runtime:
74//! enroll + heartbeat + inbound-wake loop on top of the DIDComm client
75//! * [`didcomm_session`] / [`didcomm_light`] — DIDComm transport
76//! * [`session`] — credential storage, login, refresh-token rotation
77//! * [`sealed_transfer`] — HPKE envelope (seal/open/armor/verify)
78//! * [`provision_integration`] — VP/VC bootstrap flow + typestate verifier
79//! * `integration` (feature-gated) — service-startup pull pattern with offline-cache resilience
80//! * [`did_templates`] — render-side helpers for the VTA's template registry
81//! * [`error`] — [`error::VtaError`] (typed, HTTP-aware, DIDComm-aware)
82
83pub mod error;
84pub mod hex;
85// Pure, dependency-light validators shared with clients so they apply the
86// VTA's canonical context-path / identifier rules without mirroring them.
87pub mod context_path;
88pub mod identifier;
89
90#[cfg(feature = "acl-setup")]
91pub mod acl_setup;
92#[cfg(feature = "session")]
93pub mod agent_session;
94#[cfg(feature = "attest-verify")]
95pub mod attestation;
96#[cfg(feature = "client")]
97pub mod auth_light;
98#[cfg(feature = "client")]
99pub mod client;
100pub mod context_policy;
101pub mod context_provision;
102pub mod contexts;
103pub mod credentials;
104pub mod did_key;
105pub mod did_secrets;
106pub mod did_templates;
107#[cfg(feature = "client")]
108pub mod didcomm_light;
109#[cfg(feature = "session")]
110pub mod didcomm_session;
111// Pins rustls to the aws-lc-rs backend; every binary calls this at startup.
112#[cfg(feature = "crypto-provider")]
113pub mod crypto_init;
114#[cfg(feature = "client")]
115pub mod http;
116#[cfg(feature = "keyring")]
117pub mod keyring_init;
118pub mod keys;
119pub mod prelude;
120// `resolver` wraps `affinidi-did-resolver-cache-sdk`, which is only a
121// dependency under the `didcomm` feature.
122#[cfg(feature = "didcomm")]
123pub mod resolver;
124// `protocol` itself is always-on (its `services` submodule holds pure
125// wire types + the shared `validate_service_url` validator that
126// vta-service uses without ever talking to a `VtaClient`). The
127// `impl VtaClient` blocks inside are individually `cfg(feature = "client")`-
128// gated, so disabling the `client` feature still drops the network
129// machinery — but consumers no longer need to flip the feature on
130// just to import `protocol::services::validate_service_url`.
131pub mod protocol;
132pub mod protocols;
133#[cfg(feature = "provision-client")]
134pub mod provision_client;
135#[cfg(feature = "provision-integration")]
136pub mod provision_integration;
137#[cfg(feature = "sealed-transfer")]
138pub mod sealed_transfer;
139#[cfg(feature = "session")]
140pub mod session;
141/// Canonical Trust-Task URLs for VTA operations. Mirrors
142/// `did-hosting-common::did_hosting_tasks` for the webvh-service side.
143pub mod trust_tasks;
144// DCQL credential selection + holder-bound OID4VP `vp_token` assembly. The
145// client-side counterpart to the `join-requests` / `credential-exchange`
146// protocol types: turns a verifier's `presentation_definition` + held
147// credentials into a signed `vp_token` the VTC's join verifier accepts.
148#[cfg(feature = "vp")]
149pub mod vp;
150pub mod webvh;
151
152#[cfg(feature = "integration")]
153pub mod integration;