You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reduce wire overhead and prevent identity spoofing in the recipient
identity exchange protocol:
- Slim echo: on the echo path the responder now returns only a
signature (RecipientResponse with nil RecipientData); the initiator
already holds the full RecipientData and reuses its own copy.
- Nonce/signature binding: every RecipientRequest and
ExchangeRecipientRequest carries a 32-byte nonce. The responder
signs nonce||identity with SigService.GetSigner; the initiator
verifies via SigService.OwnerVerifier before registering.
- New wire types: RecipientResponse, ExchangeRecipientResponse.
- Tests for round-trip, slim ack, malformed JSON, nonce helpers.
- Updated Mermaid diagrams and prose in docs/services/ttx.md.
Signed-off-by: SuyashAlphaC <suyashagrawalsdw@gmail.com>
Recipient-->>-Initiator: RecipientResponse (Identity + Audit Info + Signature)
30
30
31
31
Note over Initiator: 2. Assemble Request
32
32
Initiator->>+Initiator: Issue / Transfer / Redeem operations
@@ -77,14 +77,14 @@ The recipient identity protocols are implemented in `token/services/ttx/recipien
77
77
78
78
Wire messages use JSON sessions (`token/services/utils/json/session`); the diagrams name the Go types being sent or received.
79
79
80
-
**Response paths (today).** In `RespondRequestRecipientIdentityView`, after the wallet lookup:
80
+
**Response paths.** In `RespondRequestRecipientIdentityView`, after the wallet lookup:
81
81
82
-
- If `recipientRequest.RecipientData != nil`, the responder checks `OwnerWallet.Contains` for `RecipientData.Identity`, then sends **the same**`RecipientData` value back on the session (echo path). The responder does **not** substitute wallet-held `AuditInfo` / metadata into that payload; what goes on the wire is the initiator-supplied structure (after the contains check).
83
-
- If `recipientRequest.RecipientData == nil`, the responder calls `OwnerWallet.GetRecipientData` and sends that **wallet-produced**`RecipientData` (fresh path).
82
+
- If `recipientRequest.RecipientData != nil`, the responder checks `OwnerWallet.Contains` for `RecipientData.Identity`, then sends a **slim acknowledgement**(`RecipientResponse` with no `RecipientData`, only a `Signature`) back on the session (echo path). The initiator already holds the full `RecipientData` and uses its own copy.
83
+
- If `recipientRequest.RecipientData == nil`, the responder calls `OwnerWallet.GetRecipientData` and sends a full `RecipientResponse` carrying the wallet-produced `RecipientData` plus a `Signature` (fresh path).
84
84
85
-
In both cases the initiator receives a full `RecipientData` over the wire. The initiator then calls `WalletManager.RegisterRecipientIdentity` with that payload and updates the endpoint resolver. **Protocol hardening** may replace full-object responses with a minimal acknowledgement (or another minimal wire type) so the responder does not ship an entire `RecipientData` when a slimmer response suffices; that is a separate code change from this documentation.
85
+
**Nonce / Signature Binding.** Every `RecipientRequest` (and `ExchangeRecipientRequest`) carries a 32-byte cryptographic nonce generated by the initiator. The responder signs `nonce || recipientIdentity` with the private key corresponding to the returned identity (obtained via `tms.SigService().GetSigner`). The initiator verifies this signature using `tms.SigService().OwnerVerifier`**before** registering the identity. This prevents identity-spoofing attacks where a compromised session could substitute a different party's identity bytes.
86
86
87
-
**Multisig.** When `RecipientRequest.MultiSig` is true, the initiator may send an additional `MultisigRecipientData` after the first exchange; the responder registers identities and updates bindings as in code.
87
+
**Multisig.** When `RecipientRequest.MultiSig` is true, the initiator may send an additional `MultisigRecipientData` after the first exchange; the responder registers identities and updates bindings as in code. Each individual component identity is already attested through nonce/signature binding during the single-recipient phase.
0 commit comments