Crate vtc_client 

Client SDK for a Verifiable Trust Community (VTC).

The VTA SDK (vta_sdk) is the client for VTAs; this crate is the equivalent for VTCs. It lets an operator or an integration drive a VTC’s member-facing and admin-facing surface: authenticate, list members (the community roster), run the join ceremony, remove members, and manage community policy.

Two surfaces, and only one of them is a URL

The VTC answers holder verbs — the applicant side of the join ceremony — on a single document endpoint, routed by the document’s own type. Those are addressed to a community, not to a URL, so they travel over HTTPS, a mediated DIDComm session or TSP without changing. Build the client with VtcClient::connect_didcomm or VtcClient::connect_tsp (features didcomm / tsp) and they go over the session; build it any other way and they go over HTTPS.

The admin verbs cannot. Each is gated on a bearer token and a per-route Trust-Task header, which is a URL-shaped surface; a session-only client answers them with VtcError::NoRestTransport rather than failing obscurely.

The session transports are delegated to vta_sdk::client::VtaClient, which already owns session setup, thid demultiplexing, retry under one idempotency key and reply-proof verification. A second copy of that here would be a second thing to keep correct.

Any DID method can be the holder

VtcClient::submit_join_as takes a HolderKey and so signs as any DID method; VtcClient::submit_join is the did:key convenience wrapper over it. Over a session the question does not arise at all — the envelope proves the sender and the VTC never reads a document proof.

This matters because a persona minted by a VTA is a did:webvh. A client that could sign only as a did:key made every such holder borrow an identity it does not otherwise use, and the borrowed one is the DID that would have become the member.

It is deliberately thin: authentication reuses vta_sdk::auth_light::challenge_response_light (the challenge-response flow is audience-agnostic — pass the VTC’s URL and DID and the server binds aud to itself), and the join wire types are re-exported from vta_sdk::protocols::join_requests. Only the VTC-specific REST shapes (member records, pagination) are defined here.

Mount path

A VTC mounts its API under a configurable base (default /v1). Pass the full API base to VtcClient::connect / VtcClient::with_token — e.g. https://vtc.example.com/v1 — so both /auth/* and /members resolve.

The Trust-Task header is mandatory

The VTC gates every route on a per-route Trust-Task URL header (vtc-service/src/routes/mod.rs, the tt(...) wrapper) and answers 400 without it — only /health and the browser wallet’s /wallet/auth/* aliases are exempt. This client sent it on nothing, so every method failed at the transport layer regardless of its body. task holds the URL for each route and VtcClient::tt attaches it; a new method must go through that helper, not a bare self.http.get(...).

Scope

Authentication, the member roster, the admin join queue, removal, policy, the vetting admin surface (vetter grants, automatic grants, branding and statement withdrawals — what cnm vetting drives), and the applicant side of the join ceremony (VtcClient::submit_join / VtcClient::submit_join_as, which sign their own document and need no token).

Modules

join_requests

Re-export of the published join-request protocol wire types, so a consumer driving the join ceremony depends on one crate. Trust Task wire types for the VTC join-request ceremony family.

rooms

The Trust-Task URL each route this client calls is gated on, as declared in vtc-service/src/routes/mod.rs.

task

vetting

Re-export of the peer identity vetting wire types — the vetter grant, the grant listing and the automatic-grant configuration this client’s vetting admin verbs send and return. Peer identity vetting before joining a community (spec/vetting/*, spec/vtc/vetting/*) — serde shapes only; signing and verification are in crate::vetting. Peer identity vetting — how an applicant is vetted by existing members before joining a Verifiable Trust Community.

Structs

DecideResult

Outcome of approving or rejecting a join request.

EndorsementRevocation

Outcome of revoking an endorsement (DELETE /credentials/endorsements/{id}) — which is how a vetter grant is withdrawn.

HolderKey

Re-exported so a caller can name the holder key without also depending on vta-sdk directly. A VTC client that has to reach past this crate for the type its own method takes is a client with a seam in it. The key a Trust Task proof is made with: the verification method the proof will name, and the private key behind it.

JoinRequestSummary

A join request in the admin work queue (subset of the VTC’s JoinRequest).

MemberRecord

A single member of the community, as returned by GET /members. Mirrors the VTC’s MemberResponse (the fields a fleet/operator typically needs); unrecognised fields in the response are ignored.

RemoveResult

Outcome of removing a member (offboarding). The VTC flips the member’s status-list revocation bit as part of removal.

RevocationDetail

The credential a revocation applies to, and when it took effect.

VetterGrant

Outcome of naming a member a vetter (POST /vetting/vetters).

VettingRevocation

One vetting statement withdrawal notice, as GET /vetting/revocations reports it, with the admissions it touches.

VtcClient

A client bound to one VTC’s API base, holding a bearer token once authenticated.

Enums

VtcError

Errors surfaced by the VTC client.