Events

Recipients observe protocol activity through a typed, ordered event stream, deliverable by webhook.

Event vocabulary

Type	Emitted when	Notes
share.created	A grant completes
share.expiring	Expiry approaches	Reference: 7-day and 1-day warnings, deduplicated
share.expired	The consent window ends	Value access has already stopped
share.revoked	The subject revokes	Starts the cease-obligation clock
business.ceased	The recipient acknowledges a revoke
consumer.updated.<scope>	The subject updates fields in scope	e.g. consumer.updated.address covers the six address fields; delivered only for active shares whose scope intersects

Event payloads reference entities by id (share_id, etc.) and carry a monotonic sequence number per recipient. Payloads MUST NOT carry field values — recipients fetch current values through the authenticated value surface, which is released only for active shares.

Delivery requirements

• Webhook deliveries MUST be signed; recipients MUST be able to verify the signature offline (shared-secret HMAC in the reference implementation).
• Delivery MUST be at-least-once with retries and backoff; recipients MUST treat processing idempotently, keyed by event id.
• Ordering: consumers SHOULD process by sequence number; the hub SHOULD deliver in order but MUST NOT guarantee it across retries.

The update-propagation contract

consumer.updated.* is the protocol’s “change once, update everywhere” mechanism: when a subject changes a field, every recipient holding an active share whose scope includes that field receives the event and may fetch fresh values. Recipients whose shares lapsed receive nothing — data freshness is a privilege of live consent.