Events, HMAC, and three ways to get it wrong.

One — replay, when the signature carries no timestamp

An HMAC over the body alone proves the body was not altered. It proves nothing about when it was sent. Capture a genuine, correctly signed delivery once and you can resend it forever — the signature still checks out, because nothing in it says "not after". The fix binds a timestamp into the MAC itself, so an attacker cannot advance the clock without invalidating the signature, and the receiver refuses anything outside a tolerance window.

This platform's own dispatcher actually sends two signatures on every delivery, and the difference between them is this exact lesson made concrete. The legacy x-orbis-signature header is sha256=<hex> over the body alone — no timestamp bound in, kept only because an existing consumer already depends on that exact shape. Beside it, x-orbis-signature-v2 carries t=<unix-seconds>,v1=HMAC-SHA256(secret, `${t}.${body}`), and a x-orbis-timestamp header states the same seconds in the clear. A receiver that verifies only the legacy header has verified nothing about replay — it must check x-orbis-signature-v2 and refuse anything outside a 300-second window to get the property this section describes.

Two — comparing signatures with ===

A naive string comparison returns as soon as the first byte differs, and that timing difference is measurable over a network by an attacker with enough attempts. The correct comparison runs in constant time regardless of where the strings diverge — Node's timingSafeEqual, or the equivalent in any other runtime, over two buffers of equal length. A comparison that returns early is not a security check; it is a timing oracle wearing a security check's clothes.

Three — verifying a re-serialized body instead of the raw bytes

The signature was computed over exact bytes on the wire. Parse the JSON, re-serialize it with a different key order, different whitespace, or a different number formatting, and you are computing a MAC over a body the sender never signed — it will not match, or worse, it will match by coincidence on the cases you happened to test. The signature must be checked against the literal request body, before any framework middleware has touched it, and only parsed afterward.

What this platform's dispatcher actually does

Deliveries are jobs, not timers — any replica can claim one, so nothing depends on a single instance staying up. A destination is refused at registration if it is not https, resolves to loopback, or points at a special-purpose internal address — an SSRF check that runs before the URL is ever stored, not only at delivery time. A failed delivery backs off over [30, 120, 600, 1800] seconds and is dead-lettered after 5 attempts. All of it sits under the same authenticated plane the generated contract declares as BO — see the generated contract for how routes are grouped by plane in general.

The delivered body is { id, type, occurredAt, data } — there is no dedicated delivery-id header on this build, so a receiver dedupes on that id field rather than on a header. And measured against this repository's own dispatch code rather than assumed: exactly one event type is wired to fire anywhere in this platform today — item.accepted, dispatched when a holder accepts an offered wallet item. The Back Office endpoint-registration screen's own placeholder text suggests names like credential.issued and credential.revoked as examples of what an operator could type when filtering a destination's events — that placeholder is not a claim those events are ever dispatched, and this build finds no code path that fires either one.

What is real here.

curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'

Straight answers

Can I register a webhook from this page?

No. Registration sits behind the operator plane; this page names the mechanism, not a self-service form.

Is HMAC-SHA256 alone enough?

No — without a timestamp bound into the MAC, a captured delivery can be replayed indefinitely.

Does checking the signature protect against a rebinding attack on the destination host?

No, not by itself. That is a separate, delivery-time check against the resolved address — the signature only protects the body.

Is there a header I can dedupe deliveries on?

No dedicated one. Dedupe on the id field the delivered JSON body already carries.

Does this platform fire a credential.issued webhook event today?

No. Measured against the dispatch code, exactly one event type is wired to fire anywhere in this build — item.accepted.