Add optional session/call_id cross-check in bilateral verification

[willamhou]

Context

The v1 Receipt.action includes optional session and call_id fields, and these are carried into the BilateralReceipt.agent_receipt. However, verify_bilateral() does not provide a way to assert that a bilateral receipt corresponds to a specific session or call.

A caller who expects a response for call_id=abc could receive a valid bilateral receipt for call_id=xyz without detection at the verification layer.

What needs to change

Rust (crates/signet-core/src/verify.rs):

• Add optional expected_session and expected_call_id fields to BilateralVerifyOptions
• If set, verify they match receipt.agent_receipt.action.session / call_id

Acceptance criteria

• BilateralVerifyOptions gains optional expected_session and expected_call_id
• Mismatches return Err(SignetError::InvalidReceipt(...))
• Tests for match, mismatch, and unset (skip check)
• Backward compatible

Difficulty

Beginner-friendly. Simple field comparison, similar pattern to trusted_agent_pubkey.

[0xbrainkid]

The session/call_id cross-check is important — without it, a verifier cannot confirm the bilateral receipt it received corresponds to the specific interaction it initiated. This is a replay-adjacent attack: a valid bilateral receipt from a different call can be presented as proof of the current call, and verify_bilateral() has no way to detect the substitution.

The expected_session / expected_call_id option design is the right approach — opt-in field comparison keeps it backward compatible while letting security-conscious callers enforce call binding.

A few additional notes on the implementation:

Error message specificity. When a mismatch is detected, the error should include what was expected vs. what was found — not just InvalidReceipt. Debugging bilateral receipt mismatches in production (where call IDs may be UUIDs) is much easier with expected call_id=abc, got xyz.

Interaction with SATP attestation integration. For cross-org behavioral trust scenarios where SATP attestations reference Signet receipt chains, the call_id binding is what lets the attestation provider verify that a specific interaction (identified by call_id) produced the claimed outcome. Without the cross-check, an attacker could substitute a receipt from a successful interaction for one from a failed interaction, inflating behavioral trust scores.

The backward compatibility constraint (unset = skip check) is correct. This should be a strict opt-in — existing callers should not be broken by the new field.

[willamhou]

The receipt substitution attack is well-articulated — presenting a valid bilateral receipt from a different call as proof of the current call. Without call_id binding, verify_bilateral() can't detect this.

Agreed on all points:

1. Error specificity — will include expected vs actual values:

   "bilateral call_id mismatch: expected call_123, got call_456"
   

2. Opt-in design — unset fields skip the check. Existing callers unaffected:

   pub struct BilateralVerifyOptions {
       // ...existing fields...
       pub expected_session: Option<String>,   // new
       pub expected_call_id: Option<String>,   // new
   }

3. Where the check happens — compare against bilateral_receipt.agent_receipt.action.call_id (the signed value), not any external metadata.

On the SATP interaction identification point: call_id as the binding between "this interaction" and "this receipt" is exactly the bridge an attestation provider needs. Without it, there's no way to prove receipt R corresponds to interaction I — only that R exists and is valid.

Will implement alongside the nonce checker (#1) since they both extend BilateralVerifyOptions.