Hello all,
First time posting to this list. I work on cryptographic identity
infrastructure for AI agents, and Frederik Krogsdal Jacobsen suggested I bring
this discussion here after an exchange about the Deferred Token Response draft.
First, I think DTR addresses a real and growing need. Asynchronous human
approval of agent initiated requests is becoming the default pattern in agentic
deployments, and a standard protocol wait state is overdue. The DPoP binding of
the deferral code is also the right call: it guarantees that the key redeeming
the token is the key that requested it.
My concern is what key continuity does not cover during a long pending window.
Three related issues:
1. The delegation itself exists only as authorization server internal state.
The principal's consent is a database row, not a signed artifact. DPoP binds
the client key, and CAEP can refresh the principal's account state at
redemption, but the authority linking principal to agent is not independently
verifiable by anyone. Every downstream verifier is trusting the AS's
bookkeeping about what was granted, to whom, and with what scope.
2. Because deferral codes are (rightly) treated as secrets equivalent to
refresh tokens, the pending window means a redeemable claim exists as server
side state for potentially many hours. This makes the pending window a custody
problem at the AS, not only an identity state problem at the edges. A
compromise of that state during the window is difficult for either the
principal or the client to detect or disprove after the fact.
3. Revocation during the window is a policy operation rather than a
cryptographic one. CAEP events can catch a compromised or terminated principal
account. But a perfectly valid principal who simply changes their mind about
this specific delegation at hour 7 has no first class, principal held object to
invalidate. Their withdrawal of intent is routed through the AS's revocation
surface and whatever event plumbing exists downstream.
The pattern I would like DTR to be able to accommodate: the delegation
expressed as a signed, portable artifact created by the principal, carrying
scopes, expiry, and a revocation handle, presented and verified at redemption
alongside the DPoP proof. The AS would then be verifying a chain rather than
consulting its own memory. This also seems to compose naturally with the
draft's stated interest in interoperating with the AuthZEN async request
profile.
I recognize this may be out of scope for DTR itself and closer to a companion
mechanism. I would welcome thoughts on whether the working group sees the
delegation artifact question as in scope here, addressed elsewhere, or an open
gap.
Thank you to the authors for the draft.
Mitchell Rosssignedbyme.com
scorautomation.com
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
