vti_secrets/lib.rs
1//! `vti-secrets` — pluggable secret-store backends + the integration
2//! onboarding flow, shared across the Verifiable Trust Infrastructure
3//! workspace **and** external integrations.
4//!
5//! ## What this crate provides
6//!
7//! - [`SeedStore`] — the storage trait (re-exported from `vti-common`) for
8//! BIP-32 master seeds / raw secret key material.
9//! - The concrete backends ([`AwsSeedStore`], [`GcpSeedStore`],
10//! [`AzureSeedStore`], [`VaultSeedStore`], [`K8sSeedStore`],
11//! [`KeyringSeedStore`], [`PlaintextSeedStore`], and the TEE
12//! [`kms_tee`] backend), each behind the same feature flag the VTA uses.
13//! - [`create_seed_store`] — the feature-aware factory that picks a backend
14//! from a [`SecretsConfig`].
15//! - [`SecretsConfig`] — the `[secrets]` config shape.
16//! - (feature `onboarding`) [`onboarding::IntegrationOnboarding`] — the
17//! ephemeral-`did:key` → ACL-grant → auto-rotate cold-start flow, wrapping
18//! `vta-sdk`'s `SessionStore`.
19//!
20//! ## Why a shared crate
21//!
22//! These backends + the factory previously lived inside `vta-service`, so an
23//! external VTI integration (e.g. `vti-message-bridge`) could not reuse them
24//! without depending on the whole service binary crate. Lifting them here lets
25//! an integration persist its identity seed + per-connector credentials via the
26//! exact same pluggable backends the VTA uses, and onboard the exact same way.
27//!
28//! `vta-service` depends on this crate and re-exports it from
29//! `keys::seed_store`, so existing call sites are unchanged — this is a pure
30//! extraction with no behavioural change.
31
32pub mod config;
33pub mod discovery;
34pub mod seed_store;
35
36#[cfg(feature = "onboarding")]
37pub mod onboarding;
38
39pub use config::{SecretBackend, SecretsConfig};
40pub use seed_store::{SeedStore, create_seed_store};