Cargo.toml

[workspace]
members = [
  "openvtc-core",
  "openvtc",
]
resolver = "3"

[workspace.package]
description = "Open Verifiable Trust Community (OpenVTC) - First Person Protocol"
version = "0.3.1"
edition = "2024"
publish = false
authors = ["Glenn Gore <glenn@affinidi.com>"]
rust-version = "1.95.0"
readme = "README.md"
license = "Apache-2.0"
repository = "https://github.com/LF-Decentralized-Trust-labs/openvtc"

[workspace.dependencies]
openvtc-core = { version = "0.3", path = "openvtc-core", default-features = false }

# Decentralized Trust Graph Credentials.
#
# 0.2 tracks DTG Core Credentials spec v1.0 Working Draft 01. Unlike
# `trust-tasks-rs`, this one is safe to move ahead of the VTA/VTC (still on
# 0.1.3): nothing in the vta-sdk graph depends on it, so there is no second
# copy and no type that has to unify across the sdk boundary — openvtc and
# openvtc-core are its only consumers.
#
# It is also wire-compatible with a 0.1.3 peer for the credentials we
# actually exchange. The major's breaking changes are `new_vwc()`'s new
# required `task_context` argument and strict `WitnessCredential`
# deserialization; we call neither and handle no VWCs. The new `taskContext`
# field is `skip_serializing_if = "Option::is_none"` with `default`, so
# credentials we issue serialize to the same JCS bytes as before (a 0.1.3
# VTC still verifies our proofs) and 0.1.3-issued VRC/VMC/VICs still parse.
#
# The crate's documented VWC `digest` divergence from WD-01 does not reach
# us either — `digest_multibase()` / `verify_digest()` have no call sites here.
dtg-credentials = "0.5"

aes-gcm = "0.11"
# The one direct requirement in this workspace that was behind its latest
# release. Safe to move even though it derives key material: Argon2id is a
# specified KDF and `derive_argon2_key` calls `hash_password_into`, its plain
# implementation — same algorithm, version and params in, same 32 bytes out. So
# the unlock code and the `ProtectedConfig` seed are byte-identical across the
# bump and every existing config still opens. What 0.6 actually breaks is the
# `password-hash` 0.6 PHC-string surface, which we do not touch.
#
# It does not resolve the 0.5/0.6 duplicate, and is not trying to: 0.5.3 is
# `affinidi-messaging-mediator-common`'s requirement, reaching us through
# `affinidi-messaging-sdk`, and no line we control moves it. The bump puts us on
# the same copy as `vta-service` rather than on the older one.
argon2 = "0.6"
# 0.8.5 is `vta-sdk` 0.27's and `vta-service` 0.19's own requirement — the floor
# is set by the graph, and this line only records it.
affinidi-tdk = "0.10"
affinidi-data-integrity = "0.7"
# The delivery layer (D1). Replaced `affinidi-messaging-didcomm-service`, the
# type-routed framework both VTI services had already cut over from (#189).
# `-delivery` is the durable outbox + `MessagingService`; `-core` is the
# `MessageTransport` contract it builds on; `-sdk` supplies `DidCommTransport`, the
# DIDComm implementation of that contract (and the one that also surfaces inbound
# TSP off the same multiplexed pickup socket).
#
# Floor is 0.1.14 (affinidi-tdk-rs #710): the dispatcher acked every inbound
# message unconditionally, and an ack is a *delete* at the mediator — including
# when `subscribers.send` had just reported nobody listening. No subscriber is
# installed for a moment at startup and again on the way down, so whatever
# arrived in those windows was destroyed rather than redelivered. For this repo
# that window's contents are a membership credential or a join reply, which is
# the class of loss `#218`'s pickup-on-connect exists to prevent — and this layer
# was undoing it one level down.
affinidi-messaging-delivery = "0.1.14"
# Floor is 0.1.6: it marks `Protocol` `#[non_exhaustive]` and adds the
# `DIDCommV1` variant. The inbound dispatcher's wildcard arm needs both — on
# 0.1.5 the enum is exhaustively matched already and that arm is an
# unreachable pattern, which `-D warnings` rejects.
affinidi-messaging-core = "0.1.6"
# Floor is 0.19.10 (affinidi-tdk-rs #718): the release where a closed websocket
# says why it closed. The transport matched the close frame as `Message::Close(_)`
# and discarded it — `debug!("WebSocket connection closed by server")` — so a
# refused duplicate arrived here as a socket that simply vanished, and the loop
# reconnected into a duel. The mediator's `Close` now carries a reason, each with
# its own problem-report code, and the sdk surfaces the close code and reason at
# WARN. `duplicate-channel` is preserved verbatim for the genuinely-replaced
# case, so the matches on it below are unaffected. Filed from this side as
# `OpenVTC/verifiable-trust-infrastructure#1028`; the eviction *policy* is
# deliberately unchanged, because displacement is what triggers the mediator's
# stored-mail redelivery for clients that do not pull explicitly.
#
# 0.19.9 (#717) is the release that moves the messaging crates from
# `trust-tasks-rs` 0.9 to 0.11. That is not a courtesy bump — this workspace is
# on 0.11, `affinidi-messaging-sdk` carries `trust-tasks-rs` types in its own
# API (`MediatorAcl` reaches `atm.trust_tasks().account_update`), and a copy
# left on 0.9 is a *second* semver-incompatible `trust-tasks-rs` whose types do
# not unify. Same class of failure as the `vta-sdk` note below.
#
# 0.19.8 (#716) is the fix underneath it, and the one this repo chased for weeks:
# `_refresh_authentication` discarded `force_refresh`, so the websocket
# transport's proactive refresh at 80% of token life rebuilt the socket *without*
# refreshing and re-armed at 80% of the time remaining — a geometric cascade of
# reconnects per token rather than one clean cycle. See `#231`–`#234`, where the
# symptom was two listeners flapping about every 15 minutes.
#
# Earlier floors are below this one by construction: 0.19.4 (#694) was the
# `live_stream_next*` read guard that blocked `stop_websocket` for the remainder
# of a 10s poll window, so quitting the TUI mid-window paid it.
affinidi-messaging-sdk = "0.21"
# `StreamExt::next` on the `BoxStream` returned by `MessagingService::subscribe`.
futures-util = "0.3"
# Agent names (DID shortcuts). `agent-names` carries the parse /
# canonicalisation / `alsoKnownAs`-verification half; the resolver's
# `agent-names` feature is NOT default, and a direct dependency here is what
# turns it on — via feature unification — for the shared `DIDCacheClient` the
# TDK hands out. Without it `DIDCacheClient::resolve_any` does not exist.
#
# 0.1.3 is `vta-sdk` 0.27's own requirement, so it is the floor whether or not
# this line states it. Stating it keeps the manifest honest about what the graph
# actually resolves rather than implying 0.1.2 is still viable.
agent-names = "0.1.3"
affinidi-did-resolver-cache-sdk = { version = "0.8.34", features = [
  "agent-names",
] }
anyhow = "1.0"
# Structure-aware fuzzing support (issue #124). Only pulled in when a crate
# enables its own `arbitrary` feature; the `derive` feature provides the
# `#[derive(arbitrary::Arbitrary)]` proc-macro.
arbitrary = { version = "1", features = ["derive"] }
arboard = { version = "3.6.1", features = ["wayland-data-control"] }
base64 = "0.23"
bip39 = "2.2"
byteorder = "1.5"
chrono = "0.4"
clap = { version = "4.6", features = ["derive"] }
console = "0.16"
crossterm = { version = "0.29", features = ["event-stream"] }
dirs = "6.0"
dialoguer = { version = "0.12", features = ["password"] }
didwebvh-rs = "0.6"
ed25519-dalek-bip32 = "0.3"
hkdf = "0.13"
hex = "0.4"
# keyring split: the library API is now in keyring-core 1.0; platform
# backends ship as separate keyring-store crates that each binary registers
# at startup via keyring_core::set_default_store.
keyring-core = "1"
apple-native-keyring-store = { version = "1", features = ["keychain"] }
# Linux gets two backends, not one. Secret Service is the durable desktop
# store; keyutils is the kernel keyring, which is RAM-only by design and is
# now only a fallback for profiles we may not write to disk. See
# `openvtc::linux_store`. dbus-secret-service (rather than the zbus variant)
# because affinidi-tdk-common already pulls it in — one Secret Service client
# in the graph, and a synchronous one, which suits our blocking save path.
dbus-secret-service-keyring-store = "1"
linux-keyutils-keyring-store = "1"
windows-native-keyring-store = "1"
multibase = "0.9"
pgp = "0.20"
# Stays on 0.8 because pgp 0.20 does: it takes an `R: Rng + CryptoRng` from
# the rand_core 0.6 trait set for key signing / `set_password` / ESK
# encryption, and we hand it our `OsRng` directly, so the two must agree.
# rand 0.10 also drops `OsRng` outright. Re-evaluated 2026-08-09: pgp 0.20.0
# still declares `rand ^0.8.6`, and ed25519-dalek-bip32 0.3.0 is still the
# latest release. aes-gcm no longer holds this pin — it moved to 0.11 and its
# one RNG call site now fills the nonce from `rand`'s OsRng directly rather
# than going through `AeadCore::generate_nonce`.
rand = "0.8"
ratatui = "0.30"
regex = "1.12"
secrecy = { version = "0.10", features = ["serde"] }
serde = "1.0"
serde_json = "1.0"
serde_json_canonicalizer = "0.3"
sha2 = "0.11"
strum = "0.28"
strum_macros = "0.28"
sysinfo = "0.39"
thiserror = "2.0"
tokio = "1.52"
tokio-stream = "0.1"
tokio-util = "0.7"
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
# Pinned to the line the VTA/VTC themselves build against, NOT independently
# chosen. `TrustTask` crosses the vta-sdk boundary in both directions — we hand
# one to `submit`, and `capabilities` classifies the ones a VTC advertises — so
# our copy has to be the same crate version vta-sdk resolves, or the two are
# distinct types that do not unify.
#
# Moved 0.9 → 0.11 when vta-sdk went to 0.27, as it moved 0.6 → 0.9 when vta-sdk
# went to 0.25 and 0.4 → 0.6 when vta-sdk went to 0.23.3. This is a *follow*, not
# a lead: holding an older line here
# stops matching the stack and starts splitting the type — on the 0.4 → 0.6 move
# a `cargo update` alone put 0.4.1 and 0.6.5 in the same binary, which is the
# exact failure the paragraph above exists to prevent. `cargo tree -d` is the
# check: two `trust-tasks-rs` rows means this pin has drifted from vta-sdk's
# again, whichever direction it drifted.
#
# `trust-tasks-capability-client` moves with it (0.8 → 0.9) for the same reason
# — it re-exports the same `TrustTask`. Its own leading component moves one step
# per two of this crate's because it tracks its API, not the framework's;
# upstream releases the six siblings as one event for exactly this reason
# (trust-tasks-tf #250, where a sibling left behind produced
# `expected TrustTask<Value>, found a different TrustTask<Value>`).
#
# Note the check has to include the **dev** graph. On the 0.6 → 0.9 move the
# shipped graph was clean while `cargo tree -d -e normal,build,dev` still showed
# two, because `openvtc-core` dev-depends on `vta-service` for `MockVta` and
# that pin was a line behind. See its note in `openvtc-core/Cargo.toml`. The
# 0.9 → 0.11 move needed a third crate to follow as well: the messaging stack
# carries `trust-tasks-rs` types in its own API, so `affinidi-messaging-sdk` has
# a floor of 0.19.9 above for the same reason (affinidi-tdk-rs #717).
trust-tasks-rs = "0.17"
trust-tasks-capability-client = "0.17"
tui-input = "0.15"
url = "2.5"
uuid = { version = "1.23", features = ["v4", "fast-rng", "serde"] }
# The 0.27 line — the one `vta-service` 0.19 is built on, and the one that
# declares `trust-tasks-rs ^0.11`. As always this pin *follows* the VTA rather
# than leading it; see the `trust-tasks-rs` note above for why the two versions
# cannot be chosen independently.
#
# 0.25 → 0.27 crossed two minors and broke nothing here — the workspace compiled
# and tested clean with no source change. What it buys is a live defect fix that
# reaches this repo silently:
#
# 0.27.0 (VTI #1033) repairs the Trust-Task response decode. VTI #1000 folded
# Trust-Task payloads to lowerCamelCase per SPEC §4.10 but excluded
# `client/types.rs` on a stale path assumption, so the agent moved to `basePath`
# while the client went on demanding `base_path` — eleven required fields with no
# `default`, across `contexts` create/get/update/list and `keys`
# sign/rename/revoke/export-secret, failing hard on every transport. Our two
# `list_contexts()` call sites (`state_handler/mod.rs`, `context_probe.rs`) both
# sit behind `let Ok(..)`/`match`, so against a post-#1000 agent this degraded
# quietly rather than erroring: the sub-context probe simply saw nothing. The fix
# is intake aliases, not a rename, so 0.27 also still decodes an older agent's
# snake_case — safe against a VTA on either side of the fold.
#
# 0.26.0 (VTI #1012) adds `VtaClient::idempotent`, which holds one
# `idempotencyKey` across every attempt of an operation so a retried
# `create_key` is deduplicated at the VTA instead of taking effect twice. Not
# adopted here yet — our retry owner is `vta_retry()` — but it is the seam that
# eventually replaces it, and the SDK is now the layer that retries.
#
# 0.26 is not itself a viable floor: it declares `trust-tasks-rs ^0.9`, so a
# checkout resolving back to it while this workspace is on 0.11 would put two
# `trust-tasks-rs` in the binary — the same trap 0.24 (`^0.6`) posed against 0.9
# and 0.23.0 (`^0.4`) posed against 0.6.
#
# Older floor notes are gone with their lines and kept in git history rather than
# as a wall of satisfied constraints. Each recorded a defect this repo had no
# lever over: 0.23's `CreateDidWebvhRequest.add_tsp_service` (VTI #959, the field
# that lets a minted persona advertise `#tsp` at all — see
# `setup_sequence/vta.rs`), 0.25's `CreateKeyRequest.internal` (VTI #995), and
# the 0.21.x line's `provision/integration/0.2` casing (VTI #917) and `null`
# `CreateKeyBody` members (VTI #919).
#
# The graph holds exactly one `vta-sdk` and one `trust-tasks-rs`, and keeping it
# that way took a release in another repo: `did-git-sign` 0.4.5 required
# `vta-sdk ^0.25`, so until VGI published 0.4.6 on 0.27 this workspace carried
# 0.25.1 beside 0.27.0. That is the third consecutive cycle it has done so — see
# the floor note on `did-git-sign` in `openvtc/Cargo.toml`, which is where the
# obligation is written down.
#
# 0.31 → 0.32 is the fifth. Two upstream edges declare `vta-sdk` and both had to
# move first, because `"0.31"` on a 0.x crate excludes 0.32: `did-git-sign`
# (VGI #33, whose head this workspace already patches to) and `vta-service`,
# which `openvtc-core` dev-depends on for `MockVta` — 0.22 is built on 0.31, so
# the dev graph would have split even with the shipped one clean. Both are moved
# in this change. `trql-client`, the third git-pinned edge, does **not** depend
# on `vta-sdk` at all, so trust-registry stays where it is.
#
# What 0.32 buys, all of it reaching this repo through calls it already makes:
#
# VTI #1184 + #1192 are one defect in two halves. `didcomm_transport` and
# `tsp_transport` built every client with `identity: None`, so a dispatched
# Trust Task carried no `issuer`, no `recipient` and no proof — which the VTA's
# dispatch spine refuses as `malformedRequest` over DIDComm and, because the TSP
# paths back-fill those two members, as `proofRequired` over TSP. Same bug, two
# names, depending on transport. #1192 then stopped `address_trust_task`
# rewriting `issuer`/`recipient` *after* signing, which had been turning a valid
# proof into `proofInvalid` at the far end. Every Trust Task this repo dispatches
# — agent names, devices, keys, join — goes through those transports.
#
# VTI #1193 lifts Trust-Task signing off `did:key`. The signer derived the
# verification method as `<did>#<multibase>`, which only a `did:key` has, so a
# provisioned `did:webvh` integration could not sign any of the 210
# proof-requiring tasks. `ClientIdentity` gains `verification_method` for the
# methods that must name one; the two sites here that built it by hand now use
# `ClientIdentity::did_key`, which is the constructor for the one method whose
# key *is* its identifier.
#
# VTI #1191 adds `device_heartbeat_named`, which is what lets this install
# correct its own `displayName` — set once at registration and, until now,
# unchangeable. Taken here; used in the follow-up.
#
# **The floor names the patch.** 0.32.0 cannot link this repo to a VTA at all.
# VTI #1147 cut `provision/integration` to 0.3 and removed 0.2 outright, moved
# the server and the REST runner, and left the TSP runner on 0.2 and both
# DIDComm runners on 0.1 — so setup's last step died with `unsupportedType`
# against a healthy VTA. The setup wizard prefers TSP, and the failure lands
# *after* auth as a `PostAuthFailure`, which the runner treats as terminal — so
# it never falls back to the REST leg that would have worked. Every fresh
# install hit it. VTI #1200 routes all four dispatch sites through
# `ProvisionSpecVersion::CURRENT` and guards it server-side; 0.32.1 is that fix.
#
# `"0.32"` would admit 0.32.0 and resolve to it on any machine with a stale
# index — the same shape as the `did-git-sign` `"0.4.3"` floor that quietly
# admitted 0.4.5 and let a duplicate `vta-sdk` into the graph unnoticed. A floor
# that exists to exclude a specific broken release has to name it.
#
# 0.32.2 is the *reply* half of that same 0.3 cut (VTI #1202). #1200 moved the
# dispatch sites; `result_uri_for` kept a hand-written table that tested only
# for 0.2 and fell through to 0.1, so a provisioning reply went out as a 0.3
# body labelled `provision/integration/0.1#response` — a message that cannot
# satisfy the schema it names. This client does not *see* it, because it derives
# the reply type it waits for with the same function and so agrees with the
# server, wrongly, in both directions; it takes an independent client (the
# browser wallet, reading the URI from the registry bindings) to notice. Which
# is the reason to take it here anyway: a wire label this repo agrees with only
# by sharing the bug is not a contract, and the next conformance witness or
# non-Rust peer on the other end of a provisioning run is what collects on it.
vta-sdk = { version = "0.32.2", features = [
  "session",
  "client",
  # The SAME per-platform credential-store registration pnm-cli uses
  # (`vta_sdk::keyring_init::install_default_store`), so every tool in the
  # workspace puts secrets in the same place on the same OS. Pulls the
  # apple-native / windows-native / dbus-secret-service store crates.
  "keyring",
  "didcomm",
  "provision-client",
  # Routes the Trust-Task surface over TSP as a leg of the existing DIDComm
  # session (VTI #803 / #810) — no second socket, no second mediator connection.
  # This arrived across 0.20.2–0.20.6 (the leg itself, then the
  # resolver-injection seam the discovery tests need per VTI #813, then its
  # export from `provision_client` rather than the inner `resolve` module per
  # VTI #825); all of it is carried forward by the 0.21 line.
  "tsp",
  # DCQL credential selection + holder-bound OID4VP `vp_token` assembly
  # (`vta_sdk::vp`), for answering a VTC's `credential-exchange/query`.
  "vp",
] }
reqwest = { version = "0.13", features = ["json"] }
# Held at 2.x by the OpenPGP stack: pgp 0.20 and openpgp-card-rpgp 0.8 both
# declare `x25519-dalek ^2`, and we hand our `StaticSecret` straight to pgp's
# `ecdh::SecretKey::Curve25519Legacy` — a 3.x secret is a different type there
# and would not compile. 3.0 also moves to curve25519-dalek 5 / rand_core 0.10.
x25519-dalek = { version = "2.0", features = ["static_secrets"] }
zeroize = "1.8"

# Openpgp-Card Support
openpgp-card = "0.7"
card-backend-pcsc = "0.5"
openpgp-card-rpgp = "0.8"

[profile.release]
lto = true
codegen-units = 1
strip = "symbols"

# `did-git-sign` 0.4.6 — the latest published release — requires `vta-sdk ^0.27`,
# and that one edge re-splits `vta-sdk`, `affinidi-tdk`, `affinidi-messaging-sdk`
# and `trust-tasks-rs` into two copies each against this workspace's 0.31. It does
# not merely fail to unify types: `vta-keys` 0.2.9 does not compile against
# `vti-common` 0.15, so the whole workspace fails to build.
#
# OpenVTC/verifiable-git-infrastructure#33 is the release that ends it — the VGI
# workspace onto vta-sdk 0.32 and TDK 0.10, no source change, green on its own
# pipeline. Its head is a better dependency than the stale published crate, so
# this workspace takes it directly rather than waiting on the publish: the
# requirement in `openvtc/Cargo.toml` still names `0.4.6` (the version VGI carries
# at that rev), and this patch is what decides where that 0.4.6 comes from.
#
# The rev moved with the vta-sdk 0.32 bump. That is the whole reason this block
# is cheap: a published `did-git-sign` would have made 0.32 wait on a full VGI
# release cycle, as 0.23, 0.25 and 0.27 each did.
#
# Pinned by `rev`, never by `branch` — a further push to that PR must not silently
# change what this builds against. VGI's own manifest pins `trql-client` the same
# way, and both git sources are allow-listed in `deny.toml`.
#
# **Delete this whole block the moment VGI publishes 0.4.7 on vta-sdk 0.31**, and
# raise the floor in `openvtc/Cargo.toml` to name that release. `publish = false`
# here, so a git source costs this workspace nothing on its own release path — but
# it is still a dependency on an unmerged branch, which is a thing to unwind
# rather than to keep.
[patch.crates-io]
did-git-sign = { git = "https://github.com/OpenVTC/verifiable-git-infrastructure", rev = "d2c091d795168357d8bf3d1c4fffce645f2415de" }
vgi-core = { git = "https://github.com/OpenVTC/verifiable-git-infrastructure", rev = "d2c091d795168357d8bf3d1c4fffce645f2415de" }