1. Authenticate the request, not just the caller

Bearer tokens answer one question — who is calling — and stop there. They say nothing about whether the body was altered by a proxy, whether the call is a replay captured an hour ago, or whether the URL was rewritten between the client and the handler. A Never Trust pipeline cannot accept a credential that travels independently of the message it is supposed to vouch for. The signature has to cover the message.

B5 Secure binds the credential to the request itself. Every call carries a keyed HMAC computed over a canonical representation of that specific request, with a timestamp-expiry window and a single-use nonce. A captured request cannot be resent; an altered request fails verification. Identity and integrity are proven in one operation, at the edge of the pipeline, before any handler runs.

2. Today: the canonical form B5 signs

The signature is only meaningful if both sides compute it over exactly the same bytes. B5 Secure defines a strict canonicalization so that semantically identical requests produce identical input to the MAC, and any meaningful change produces a different one. The signed string binds, at minimum:

• the HTTP method and the full request URL (path and ordered query);
• a cryptographic hash of the body, so payload tampering invalidates the signature without the verifier buffering the whole body twice;
• a timestamp that fixes the request to a moment in time;
• a unique nonce that makes each signed request single-use;
• the calling identity (the AuthUrn) so a signature minted for one identity cannot be presented as another.

The MAC is computed with the caller’s secret over that canonical string. Because the identity is inside the signed material, a valid signature is non-transferable between identities — a property bearer tokens lack entirely.

3. Replay and tamper defense

Two mechanisms close the replay window. The timestamp is checked against a configurable acceptance skew; anything outside the window is rejected outright, which bounds how long a captured request could even be a candidate for replay. Within that window, the nonce is recorded in a short-lived store and rejected on reuse, so a request that is replayed inside the skew still fails. Tampering is defeated by construction: the body hash and URL are signed, so a modified call cannot reproduce the MAC without the secret.

4. The 2026 edge: RFC 9421 and crypto-agility

The 2026 extension preserves the contract above and makes two additions. First, B5 Secure aligns its signing to RFC 9421 (HTTP Message Signatures) — the IETF standard for signing an explicitly enumerated set of components with a published algorithm identifier — so signatures interoperate with standards-aware gateways and clients instead of relying on a bespoke scheme. Second, the primitive becomes crypto-agile: the algorithm is resolved through a provider, not hard-coded, so an HMAC signature, an Ed25519 signature, or a post-quantum ML-DSA (FIPS 204) signature are configuration choices behind the same calling convention.

This is what makes harvest-now-decrypt-later a non-event for request integrity: when ML-DSA is the right answer, you change the configured algorithm and rotate keys — the canonical form, the pipeline placement, and the application code are untouched. Keys themselves are held by reference in the HSM (see FIPS 140-3 Level 3), never marshalled into process memory.

5. The calling convention

Signing is a pipeline concern, not application code. You declare the scheme and the algorithm provider; B5SecurityKit computes and verifies signatures around your handlers. The application never sees raw key material.

// One pipeline, algorithm resolved by reference — HMAC today, ML-DSA on a flag
services.AddB5SecurityKit(o => {
  o.Signing.Scheme      = SigningScheme.HttpMessageSignatures; // RFC 9421
  o.Signing.Algorithm   = CryptoProfile.Current;          // agile: HMAC | Ed25519 | ML-DSA
  o.Signing.ClockSkew   = TimeSpan.FromSeconds(30);
  o.Signing.Replay      = ReplayStore.DistributedNonce;
});

// Handlers stay clean — the signature is verified before this runs
[Permission("transfers.create")]
public async Task<Result> CreateTransfer(TransferRequest req) => ...;

6. What an attacker actually gets

Consider an attacker on the path who captures a fully valid signed request. They cannot replay it: the timestamp ages out, and inside the window the nonce is already burned. They cannot alter it: any change to the body, URL, or method breaks the MAC. They cannot retarget it: the calling identity is inside the signed string, so it cannot be presented as another principal. They cannot forge a new one: without the secret — which lives in the HSM, not in the client — they cannot produce a valid MAC. A leaked API key narrows but does not open the door, because IP-firewall binding and key-leakage protection constrain where a key may be used at all.

7. Where this lands in an audit

Request signing is the concrete control behind several review questions. It evidences integrity and non-repudiation of API calls (SOC 2 CC6.1, CC7.2), satisfies expectations for protecting data in transit beyond transport encryption, and — with the agile profile — demonstrates a credible post-quantum migration path for cryptographic assurance under NIST’s crypto-agility guidance. RFC 9421 alignment lets you point to a published standard rather than defending a proprietary scheme.

Next: Multi-Factor — a second factor where the risk is →