pub trait TransportHandler {
// Required methods
fn binding_uri(&self) -> &str;
fn derive_parties(&self) -> TransportContext;
// Provided methods
fn prepare_outbound<P>(&self, _doc: &mut TrustTask<P>)
where P: Serialize { ... }
fn resolve_parties<P>(
&self,
doc: &TrustTask<P>,
) -> Result<ResolvedParties, ConsistencyError> { ... }
fn reject<P>(
&self,
doc: &TrustTask<P>,
id: impl Into<String>,
reason: RejectReason,
) -> Option<TrustTask<ErrorPayload>> { ... }
}Expand description
A transport binding’s plug-in for the framework.
Implementations represent one transport (REST + mTLS, DIDComm, TSP, an in-memory test loopback, …) and supply the transport-derived information the framework needs to apply SPEC.md §4.8.1 precedence.
The trait is sync and object-safe; transports that perform I/O do it outside the trait (e.g. before constructing the handler with the values it already extracted from a verified envelope).
Required Methods§
Sourcefn binding_uri(&self) -> &str
fn binding_uri(&self) -> &str
A stable identifier for this transport binding, suitable for logs and audit (SPEC.md §9.1, §9.2 — “A transport binding specification SHOULD identify itself by a stable URI”).
Sourcefn derive_parties(&self) -> TransportContext
fn derive_parties(&self) -> TransportContext
Identities the transport authenticated for the inbound message under consideration.
Implementations construct the handler with whatever the transport
extracted (peer certificate subject, verified DIDComm sender,
authenticated routing key, …) and return it here. Returning a
fully-empty TransportContext is valid for transports that provide
no authenticated identity — the framework then falls back entirely to
the in-band members and any proof they carry.
Provided Methods§
Sourcefn prepare_outbound<P>(&self, _doc: &mut TrustTask<P>)where
P: Serialize,
fn prepare_outbound<P>(&self, _doc: &mut TrustTask<P>)where
P: Serialize,
Prepare an outbound document for emission over this transport.
Per SPEC.md §9.2 item 1, a producer-side handler MAY strip issuer /
recipient when the transport will provide authenticated identity
for those roles end-to-end. The default implementation leaves the
document untouched, which is the conservative choice (in-band values
remain visible to downstream consumers regardless of transport).
Sourcefn resolve_parties<P>(
&self,
doc: &TrustTask<P>,
) -> Result<ResolvedParties, ConsistencyError>
fn resolve_parties<P>( &self, doc: &TrustTask<P>, ) -> Result<ResolvedParties, ConsistencyError>
Apply SPEC.md §4.8.1 precedence to produce the final
ResolvedParties for an inbound document.
Returns ConsistencyError when an in-band member is present and
disagrees with the transport-derived value for the same party. The
caller is responsible for translating the error into an
identity_mismatch error response (SPEC.md §8.3).
Sourcefn reject<P>(
&self,
doc: &TrustTask<P>,
id: impl Into<String>,
reason: RejectReason,
) -> Option<TrustTask<ErrorPayload>>
fn reject<P>( &self, doc: &TrustTask<P>, id: impl Into<String>, reason: RejectReason, ) -> Option<TrustTask<ErrorPayload>>
Build a trust-task-error response for doc that satisfies the
SPEC.md §8.1 routing rules — most importantly, the rule that under
RejectReason::IdentityMismatch the error MUST address the
transport-authenticated sender and MUST NOT address the contested
in-band issuer.
Returns Some(ErrorResponse) when a routable recipient exists, and
None when the rejection is identity_mismatch and the transport
has no authenticated sender for the inbound document — per §8.1, the
consumer SHOULD NOT emit a response in that case.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".