Summary

  • RFC 9770 lets an ACE Authorization Server expose and notify a Token Revocation List, but it explicitly recognizes a window in which a token is revoked at the server and still accepted by a Resource Server that has not learned the change.
  • The useful receipt chain is longer than a revocation record: AS decision, TRL update, query or Observe delivery, receiver processing, local token expungement and a measured later request each answer a different question.

Revocation is often narrated as a switch: authority exists, somebody revokes it, and the device can no longer act. That description hides the distributed system in the middle. In constrained environments, the authorization decision may be made at one machine while the Resource Server that enforces it is intermittently connected, conserving energy, carrying a local token store or missing an update.

RFC 9770 gives that middle a useful, deliberately limited protocol. It is a 2025 Standards Track document by Marco Tiloca, Francesca Palombini, Samuel Echeverria and Grace Lewis. In ACE, registered clients and Resource Servers can obtain a Token Revocation List, or TRL, from the Authorization Server using CoAP. They can ask for a current full view, request differences, or subscribe through CoAP Observe. The list contains hashes identifying access tokens that have been revoked but have not expired.

That is real coordination. It is not an instantaneous physical recall of every token. The RFC explicitly leaves outside its scope both the process by which a token is declared revoked and the method by which the Authorization Server learns that it should be. A hash appearing in a TRL therefore establishes neither why a policy changed nor whether the underlying decision was correct. It is evidence that the AS has made its own update, not a portable verdict about the entire history of an access request.

The delivery boundary is equally material. After the TRL changes, the AS sends Observe notifications to subscribed devices whose relevant subset has changed. But a notification sent is not a notification received. RFC 9770 warns that an attacker able to suppress notifications can keep a requester from ever learning that its token was revoked. It consequently says requesters should not rely solely on Observe and should poll for the current list under an application policy that accounts for their availability and operating pattern.

The document also refuses to make silence legible. A requester that receives no response or an error must draw no conclusion about revocation or expiration. A failed retrieval is not proof of continuing validity; it is not proof of withdrawal either. Diff histories can be bounded, and an old series item can disappear before a later query. Full retrieval has its own constrained-device cost, because a device may not be prepared to handle a large relevant list. Those are operational trade-offs, not gaps that a dashboard label can erase.

There is a hard local rule once the relevant information actually arrives. A registered device that receives a TRL response must expunge each stored access token associated with a listed hash. An RS must retain the hash after expunging the token. That requirement is valuable precisely because it names a receiver-side state transition. But it does not reach backward to prove the AS's earlier notice arrived, sideways to prove every peer made the same transition, or forward to prove that a client was denied on every protected resource.

RFC 9770 names the remaining exposure without softening it: a client can access a resource after its token has been revoked but before the RS is aware. If the RS still holds the token, the access can succeed even though it should not, and the RFC calls this a security violation. That sentence turns a generic “revoked” status into a concrete evidence discipline.

Heng Lu's insistence on a minimum common surface helps read the boundary correctly. The TRL mechanism makes a narrow statement portable. The actually decisive acts—reachable server, accepted CoAP exchange, polling cadence, local-store mutation and protected-resource decision—remain at running systems. They should be logged and evaluated there, rather than being borrowed from the existence of a central list.

Sources