Deonté, You asked for public, versioned specifications. One covers part of this, for one deployment shape, and I would rather state its limits than have them found:
https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/ <https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-sweeney-wimse-credential-delegation/&source=gmail&ust=1792587702545000&sa=E> (revision -01) The shape: a Delegation Server holds credentials users have deposited, and agents act only by asking that server to make the call. The agent never holds the credential. (1) Consumption versus commit. Section 6.1 has the server validate the delegation and then make the upstream call itself, and Section 7 item 3 requires it to refuse any in-flight exercise request that presents a revoked token. So for the calls it mediates, the authority check and the dispatch happen at one enforcement point, and the record of the call is written by the party that actually admitted it. What it does not establish is what the resource server does after accepting the call. An effect the resource server queues and commits later is outside what the Delegation Server can see. (2) Revoked epoch across administrative domains. Not solved. Section 7 cascades revocation to every descendant token the same server issued, within stated bounds (1 second for the token, 5 seconds for descendants). Across servers or domains it says nothing. -02 will say so explicitly instead of leaving it implied. (3) Unknown downstream paths. Section 6.3 lets the server exchange a delegation for a token presented directly to a resource server. Once that happens the server is off the path. The revoked_count that Section 7 returns reports invalidation, not closure, so for that path the honest result is PARTIAL unless the resource server checks authority at commit. -02 will state that too. On reproducible tests: the open-source implementation ( https://github.com/cred-ninja/sdk <https://www.google.com/url?q=https://github.com/cred-ninja/sdk&source=gmail&ust=1792587702545000&sa=E>) implements the mediated path. Section 9.1 of the draft lists what it does not do yet. Relevant here: it has no DELETE /delegation/{jti} endpoint or revoked_count, and the 1-second and 5-second bounds are not measured by tests. Treat the timing as specified, not demonstrated. One point the three cases share: a closure claim is only worth something if it names the enforcement points it covers. A CLOSED from a party about a sink it does not gate is the failure to prevent. The same point is why Caleb's R6 and R7 cannot both hold beyond a token's lifetime. A verifier that never calls back cannot learn of a revocation before the token expires, so "immediate, everywhere" needs either a gate in the path or a short lifetime. Kieran On Mon, Oct 19, 2026 06:33 AM, Deonté O’dell Watts <[email protected]> wrote: > Hello OAuth WG participants, > > Thank you to Caleb for the 13 candidate negative scenarios and to Ornella > for pointing to GUARDAID and Guardalpha as possible related approaches. > > I will keep those contributions distinct from validated test outcomes or > WG requirements. In particular, an audit chain that records when a ticket > was issued or an action was dispatched does not by itself establish that a > downstream system cannot subsequently commit a queued effect. That stronger > conclusion appears to depend on the actual enforcement boundary, trusted > timestamps, downstream cooperation, and any permitted settlement exceptions. > > For prior-art comparison, could the proponents point to publicly > accessible versioned specifications or reproducible tests defining: (1) > when a ticket is consumed versus when a consequential action commits, (2) > how a revoked epoch is enforced across administrative domains, and (3) how > unknown downstream paths or already-accepted obligations are represented? A > precise public link and any documented limitations are sufficient; no > private materials are requested. > > These are requests for technical references, not endorsements of an > architecture, claims of physical certification, an agreement to meet, or a > proposal to change OAuth standards. My revocation-closure document remains > an individual Internet-Draft. > > Regards, > Deonté O’dell Watts > Independent Researcher | GoodShyt Group Inc. > ORCID: 0009-0005-8586-3650 > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
