1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
//! [`DidcommHandler`] — the framework's [`TransportHandler`] for DIDComm
//! v2.1.
//!
//! Constructed per-exchange (one per inbound message on the consumer
//! side; once per peer on the producer side). The handler reports the
//! locally-controlled DID as `recipient` and the DIDComm-verified peer
//! DID as `issuer`, then lets the framework's default
//! [`TransportHandler::resolve_parties`] apply SPEC.md §4.8.1
//! precedence unchanged.
use ;
/// Stable identifier for the DIDComm binding, per SPEC.md §9.2.
///
/// `bindings/didcomm/0.2` §1. The binding identifier moved with the minor;
/// the envelope `type` ([`ENVELOPE_TYPE`](crate::ENVELOPE_TYPE)) deliberately
/// did not, so a 0.1 and a 0.2 implementation stay mutually intelligible on
/// the wire (binding §7.1).
pub const BINDING_URI: &str = "https://trusttasks.org/binding/didcomm/0.2";
/// A [`TransportHandler`] for one DIDComm v2.1 exchange.
///
/// `local` is the DID this party controls. `peer` is the
/// authcrypt-verified sender DID on the consumer side, or the configured
/// remote DID on the producer side.
///
/// Both fields are `Option<String>` so a caller can model a party it has
/// not established. The consumer path in [`unpack_trust_task`](crate::unpack_trust_task)
/// never leaves either side `None`: binding §2/§4 admit only authcrypt, which
/// always yields both a verified sender and the DID it was sealed to. A
/// handler built with `peer = None` makes the framework fall back entirely to
/// the document's in-band `proof`, so construct one only where that is what
/// you mean.