The direct answer
A valid callback signature does not by itself authorize a business change. Verify the agreed message protocol, bind the result to the server-owned job, enforce its current state, and coordinate duplicate handling with the intended effect before acting.
Give the receiver five separate questions
An assistant starts a background summary job. Later, an HTTP callback says the result is ready. Accepting that message might attach a draft to a ticket, advance a workflow or queue another action. A callback endpoint therefore needs more than an event name that sounds familiar.
Ask five questions independently: Is this the expected sender? Is this message acceptable now? Does it belong to this job and owner? Is the state transition allowed? Has the business effect already been recorded or applied? A failure at any gate must not become permission to act. The design below uses fictional jobs and proposed checks only. No signature, model, provider callback or business operation has been tested.
Verify the protocol that the sender actually implements
RFC 9421 defines signatures over selected HTTP message components. It requires an application to decide sufficient coverage; a cryptographically valid signature covering irrelevant fields is insufficient. Use the actual sender's documented protocol and a maintained implementation, with expected keys, permitted algorithms and required components configured by trusted application settings.
If that protocol protects content through a digest, verify the content and that the digest field has the required signature protection. RFC 9530 defines digest fields and explains their use with signatures. A standalone hash does not establish who sent the content. Follow the protocol's content and canonicalization rules; do not invent a parse-and-reserialize shortcut.
Freshness is another decision. RFC 9421 discusses timestamps, expiry and nonces for replay resistance. Define the accepted clock window, skew handling and replay storage according to the selected protocol. Those controls do not establish business uniqueness. A legitimate retry can carry a fresh signature while referring to an already processed event. Key rotation and proxy transformations also need protocol-specific verification; this guide supplies no universal signing recipe.
Create a job record the callback cannot rewrite
For the synthetic exercise, job J-04 belongs to workspace W-A. The application stored expected sender Sandbox Service, remote job PJ-88, target ticket T-17 and one permitted effect: attach a draft note. The callback may report a result; it may not choose a new workspace, ticket or operation.
Look up that trusted record and compare the received identifiers with it. Treat identifiers and the returned text as untrusted input even after authentication. Apply payload bounds and result validation separately. A valid message saying “send this draft externally” does not enlarge the recorded job's authority. If the initiating user's authority has expired, the application must follow its defined revocation policy before applying an effect.
For this example, the allowed success path is running to result_received, followed by completed only after the authorized effect is confirmed. OWASP REST guidance recommends server-side workflow-state validation. Do not rely on the sender or a client interface to keep transitions in order.
Use an acceptance, state and effect matrix
Each row is a proposed independent case. “Authenticated” means a stub supplies that result to test application decisions; it is not evidence of real signature verification. The receiver's acknowledgement must follow the real delivery contract. An acknowledgement never proves the downstream effect completed.
| Incoming case | Proposed receiver decision | State and effect expectation |
|---|---|---|
| Fresh authenticated E-1 for running J-04 | Accept after job and result checks | Record result_received and one draft-note intent |
| E-1 delivered again with a fresh valid signature | Recognize the same event and content | Return recorded disposition; no new intent |
| Expired message or forbidden nonce reuse | Reject under protocol rules | No business change |
| Authenticated sender, but remote job belongs to W-B | Reject job binding | Leave J-04 unchanged |
| Authenticated payload changes target to T-99 | Reject inconsistent target | No note on either ticket |
| E-1 reused with different result content | Hold as a conflicting duplicate | No replacement or second intent |
| Failure arrives after J-04 is completed | Record late conflict for reconciliation | No terminal-state downgrade |
| Two completion events race with different event IDs | Coordinate the job transition | At most one permitted draft-note intent |
Coordinate the record and the effect
A separate “have I seen this event?” read followed by an insert can race another receiver. For the proposed design, durably coordinate event identity, content fingerprint, current job transition and effect-intent creation in one supported transaction or equivalent fenced operation. Scope event identity to the expected source and integration. A unique event ID alone cannot stop two different completion IDs from advancing the same job twice.
The external effect is a separate boundary. A worker might attach the note and crash before recording confirmation. If the destination supports a suitable idempotency key, bind it to the trusted job and effect. Otherwise reconcile the uncertain outcome before retrying. Even with a key, verify the destination's scope and retention behavior. Do not claim exactly-once delivery or execution across independent services.
Keep accepted, effect_pending, effect_confirmed and effect_unknown distinct in operator records. Persist enough minimized metadata to explain the disposition without copying prompts, credentials or complete result bodies into ordinary logs. Repeated receipt should consult the durable disposition rather than repeat the action.
Review the application boundary before production use
A useful next check would run the matrix against a local receiver harness with an intercepted effect recorder, including concurrent completion and a crash after simulated external success. Expected decisions should be fixed before the run. This exercise remains unrun, and its stubbed authentication cannot validate keys, signature parsing or a provider integration.
Boundary's planned request router does not provide this callback verifier, job-state transaction or downstream idempotency service. Its separate eight mock policy checks do not establish callback safety. Keep protocol verification, application-state evidence and actual effect confirmation as separate release requirements.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.