Webhook／イベントプロトコル

Event-driven agent triggers are often described as if webhook delivery were exactly-once or as if every webhook had one standard. CloudEvents provides a precise envelope/binding reference, but delivery, retry, ordering, identity, and replay remain deployment contracts.

interoperability / non-LLM component / implementation / operability / security / governance

What does CloudEvents v1.0.2 standardize about event context, data, formats, and protocol bindings, and what must an enterprise webhook/event implementation specify separately?

[S1] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents Specification | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md | PUBLICATION_UPDATE_ACCESS: fixed tag v1.0.2; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: v1.0.2 | SUPPORTING_LOCATOR: context/data/event-format/message/protocol/binding lines 251-275; specversion lines 351-355; source/id uniqueness and duplicate guidance lines 316-334 in the recorded web capture | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for event-envelope and binding facts; limit for delivery guarantees. [S2] SOURCE_CLASS: official_spec | EXACT_TITLE: CloudEvents HTTP Protocol Binding | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocol-binding.md | PUBLICATION_UPDATE_ACCESS: fixed tag v1.0.2; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: v1.0.2 | SUPPORTING_LOCATOR: HTTP binding document: structured and binary mode mapping of CloudEvents to HTTP; binding is transport-specific and must be read with the core spec | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for HTTP webhook mapping; limit because a binding is not a delivery/SLO contract. [S3] SOURCE_CLASS: official_project_docs | EXACT_TITLE: CloudEvents | AUTHOR_ORG: Cloud Native Computing Foundation CloudEvents project | CANONICAL_URL: https://cloudevents.io/ | PUBLICATION_UPDATE_ACCESS: project page accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: project page current; no extra version promoted | SUPPORTING_LOCATOR: canonical project page and CloudEvent v1 context-attribute reference | EVIDENCE_LABEL: VERIFIED_SPEC + PRODUCT_VOLATILE | RELATION: context only; fixed tag S1 remains normative boundary.

• ESTABLISHED [S1 support]: CloudEvents separates event context metadata from domain-specific data, defines event formats, messages, protocols, and protocol bindings. The core spec names HTTP, AMQP, MQTT, SMTP, Kafka, NATS, and vendor-specific transports as possible delivery protocols.
• ESTABLISHED [S1 support]: In v1.0, specversion identifies the CloudEvents specification version; source and id are required, and producers must make source+id unique for each distinct event. A resent duplicate may retain the same id, and consumers may treat identical source+id as duplicates.
• INFERENCE [S1+S2]: CloudEvents source+id can support consumer idempotency/deduplication design, but it does not by itself provide exactly-once delivery, ordering, retry, authentication, signature verification, dead-letter handling, or business transaction atomicity.
• ESTABLISHED [S1 limit]: A protocol binding describes how events are sent/received over a transport; it may use structured or binary mode. The existence of a binding does not establish a universal webhook delivery behavior.

The core v1.0.2 page has no universal idempotency, retry, ordering, or exactly-once guarantee; the packet therefore preserves those as deployment unknowns. HTTP success can be lost before consumer processing is durable; retries can duplicate side effects; events can arrive late/out of order; signatures/auth, payload schema, replay window, and poison-event handling may differ. CloudEvents envelope conformance does not prove that a producer sends truthful context or that an agent action is safe.

CloudEvents version and binding; HTTP endpoint/TLS; authentication/signature/replay protection; source/id generation; event type/schema/content type; producer/consumer compatibility; retry/backoff/timeout; deduplication/idempotency store; ordering/partition key; DLQ/quarantine; payload size/redaction; tenancy/region; observability and retention; downstream agent approval and side-effect policy.

Evidence-only desk research. No webhook endpoint was created, called, replayed, or connected to an agent.

No delivery, duplicate, out-of-order, retry, signature, throughput, or recovery test was run. CloudEvents specification is not a delivery benchmark.

Treat event payload/context as potentially sensitive. Verify issuer/signature, freshness, audience, source, type, schema, and replay status before enqueueing. Persist event ID and processing outcome for deduplication; log receipt, validation, queue, agent decision, tool execution, retry, and final disposition. Cost includes ingress, queue, storage, retries, agent tokens, downstream action, and human approval; not measured.

「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」

Future update Work should pin CloudEvents core and binding tags, then create a non-destructive TEST_PROFILE for malformed event, duplicate source+id, replay, delayed/out-of-order delivery, lost acknowledgment, signature failure, schema evolution, DLQ, dedupe store outage, and agent approval. Keep webhook transport, event envelope, queue semantics, and agent execution as separate claims.

current tag/binding parity; signature/auth profile; producer truthfulness; delivery/retry/order guarantees; dedupe durability; schema registry; DLQ/replay policy; tenant isolation/data residency; event-to-agent cost/SLO; public incidents.

Do not infer exactly-once or at-least-once from CloudEvents envelope fields alone. Do not call CloudEvents a universal webhook delivery guarantee or treat source+id as proof that a side effect is idempotent. UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

---