+1 to Thilina This is close to Introspection, single Logout, StatusList, and OpenID’s Shared Signals Framework.
Have you looked into those Deonté? From: Thilina Senarath <[email protected]> Sent: October 15, 2026 12:42 PM To: Deonté O’dell Watts <[email protected]> Cc: [email protected] Subject: [EXT] [OAUTH-WG] Re: Revocation closure semantics for delegated agents: scoping and queued effects CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. Hi Deonté, Revocation propagation and cancellation of downstream operations are established challenges in distributed systems. What specific gap in existing OAuth and distributed authorization mechanisms does the proposed revocation closure model address? Additionally, which properties of this model are unique to AI agents rather than general delegated workloads? On Thu, Oct 15, 2026 at 1:06 PM Deonté O’dell Watts <[email protected]<mailto:[email protected]>> wrote: Hello OAuth WG, I would appreciate feedback on a narrow interoperability question connected to existing agent-authorization and revocation work. RFC 7009 addresses token revocation, and draft-chen-oauth-agent-revocation-00 explores agent-level cascade operations. My individual Informational draft, draft-watts-oauth-agent-revocation-closure-01, separates three events: receipt of a revocation request, invalidation of authority artifacts, and an evidence-backed claim that consequential operations within a declared scope can no longer commit using the revoked authority epoch. Document: https://datatracker.ietf.org/doc/draft-watts-oauth-agent-revocation-closure/ Concrete scenario: A delegated agent is revoked after an asynchronous operation has been queued and after a derived token has been issued. An upstream endpoint reports completed revocation, while a downstream job can still commit. The draft models this using scoped closure, enforcement cut sets, unresolved-path statuses, and authority epochs. This is intended to complement existing OAuth work, not change RFC 7009 or introduce a new grant type. I would value WG guidance on: 1. Whether any existing draft already defines the interoperable conditions for asserting downstream effect closure, as distinct from invalidating tokens or returning cascade counts. 2. Whether an interoperable scoped closure indication is useful across administrative domains, or whether it should remain implementation-local. 3. If this merits WG attention, whether narrow requirements and negative test vectors would be more valuable than a new protocol object. I am particularly interested in contrary examples or prior art demonstrating that current semantics already cover this case. The current document is an individual I-D, not a WG-adopted document. Regards, Deonté O’dell Watts Independent Researcher | GoodShyt Group Inc. ORCID: 0009-0005-8586-3650 https://datatracker.ietf.org/doc/draft-watts-oauth-agent-revocation-closure/ _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
