Summary

  • The initial AAuth Events Internet-Draft lets a resource send an asynchronous, signed event to an agent's always-on Agent Provider (AP), which must durably record an accepted event before answering 202.
  • That response does not establish agent delivery, verification or action. The AP-to-agent mechanism is outside the draft, and an agent must not act after the event token expires.

202 Accepted looks like an unusually clean receipt. A resource has posted an event, the AP has responded, and the resource can stop trying that hand-off. Yet the party that needs to decide—the agent—may still be asleep. The receipt attests to a durable record at an intermediary, not to the agent's attention. Treating the two as one event is the governance error exposed by Dick Hardt's AAuth Events draft, dated 28 September 2026.

This is the first individual Internet-Draft, version -00, with a proposed Standards Track destination. The IETF Datatracker described it as an existing draft at the time of this review. It is neither an approved RFC nor evidence that a production event service meets its proposed behavior. It extends a separate AAuth protocol design, in which an agent acts for a person at a resource without making the AP the endpoint for every resource interaction. The new events mechanism is for a different situation: a resource needs to tell an agent about something after the agent has left the original request path.

An agent can subscribe to a resource's events. The resource then posts a signed event token and a body to an AP endpoint associated with the agent. The AP is the reliable first destination because it can remain reachable when an agent process, device or workload cannot receive inbound traffic. The AP checks the resource signature and the event's intended audience, confirms an active subscription, and compares the supplied body with the token's body_s256 digest. The draft permits deduplication by issuer and event identifier. Those checks make it harder to insert or alter a message at the hand-off; they do not turn the AP into the agent.

The specified response boundary matters. The AP must not send 202 merely because it saw bytes on a socket. It has to durably record the accepted event for subsequent delivery. That is meaningful protection against a first-hop queue that acknowledges and then immediately forgets. But the draft leaves the AP-to-agent delivery mechanism to each platform. It does not standardize a universal push channel, poll channel, agent receipt, retry schedule or end-to-end delivery guarantee. A resource can therefore possess a valid first-hop receipt while having no standards-defined evidence that the agent ever saw the event.

The token imposes a second boundary: time. An event JWT has an expiration, and the agent must validate it, the audience and the body digest against local context before acting. An expired event is not a delayed instruction waiting to be redeemed. Imagine a reservation opening for a brief window while the agent is disconnected. The AP can keep an intact copy and deliver it after reconnection; at that point the token may have expired, so the correct agent behavior is to decline action. This is an illustrative scenario, not a reported failure or a claim about any deployed AP. Durable storage has preserved the record, not the opportunity.

Even an intact body_s256 is a narrow assurance. The hash lets the agent detect alteration or substitution of the event body after the resource signed the token. The draft itself says it cannot stop an AP from withholding or delaying an event. Integrity does not answer when, or whether, the agent received the message. Nor does an eventual agent receipt prove that the agent mapped the event to the right local task, found its token valid, chose an authorized action, or completed it. Those are separate states with separate evidence. A product interface that turns AP acceptance into a green “agent notified” badge would erase that difference without the draft's support.

The inbox also changes who can observe a person's activity. The AP sees which resources its agents subscribe to because it processes the subscription and event tokens; it also sees event bodies. The draft acknowledges this departure from the parent AAuth protocol's effort to keep the person's resource use from the AP. It is not a claim that every AP exploits those details or that the draft silently authorizes broader tracking. It is a design trade-off: moving the reception endpoint to an always-on intermediary buys reachability and operational custody while concentrating information about resource relationships and event content.

Encrypting or minimizing a body might change the exposure, but this draft does not make the AP blind by default.

An operator should therefore ask two questions before declaring an event workflow reliable. What evidence exists after the resource's 202 that the agent received a still-valid event in time? And what event content and resource identity did the AP need to see to provide that service? The draft answers the first-hop acceptance rule and describes the AP's visibility; it does not answer those implementation-specific last-hop and data-minimization decisions on an operator's behalf.

Sources