Hi Mohamad, I don't think that will work because the whole point of deferred token responses is that the user agent may not be available at the time the AS makes the decision to respond with a token. So it runs counter to our goals to require that the initiating user needs to do anything at the decision time. But feel free to correct me if I misunderstood what you meant.
Cheers, Frederik On Wed, 29 Jul 2026 at 09:28, Mohamad Khalil Yossif <mohamad= [email protected]> wrote: > > Frederik, Mitchell, > > Coming in on one narrow point, because I think Frederik's objection is > answerable and the answer changes the shape of the problem rather than > requiring a profile. > > The objection, as I read it: cancelling a deferred request needs the > initiating entity to reach the AS directly, which needs a channel that > does not exist, so it belongs in a higher-level profile. > > That holds if cancellation is a signal the initiating entity sends. It > does not hold if issuance is instead conditioned on evidence that the > delegation is still live - evidence produced on the user side and > presented by the client, with no channel to the AS at all. > > Concretely, inverted: rather than the user telling the AS to stop, the > AS declines to issue without a fresh artifact the user's authenticator > produced. The client carries it because it must, not because it is > trusted to. Withdrawal is then the absence of a new artifact, which > requires no message, no endpoint, and no direct relationship between > the initiating entity and the AS. Silence is the cancellation. > > This bears on Mitchell's two cases specifically. > > For a hosted platform where the client registration belongs to the > platform and not the user, the user has no revocation authority over > the client and should not - and under the above they do not need any. > What they withhold is their own artifact, which affects their own > delegation and no other tenant's. That is the blast radius Mitchell > says client-granularity revocation gets wrong. > > For a steered rather than compromised client, the same. A prompt > injected agent continuing to run other tasks correctly is exactly the > case where per-client revocation is the wrong instrument. If the > deferred issuance requires an artifact bound to the specific action's > parameters, a steered client cannot obtain one for the action it was > steered into, while everything else it is doing legitimately continues > to work. The failure is scoped to the transaction because the evidence > is. > > Two honest limits on this, since I would rather state them than have > them found. > > It requires the artifact to be unforgeable by the client, which means > it has to be produced somewhere the client cannot reach - a > user-verification-gated key on the user's authenticator, not a value > the client computes or holds. Where that is not available the argument > collapses back to Frederik's, and a profile is the right answer. > > And it does not establish ordering against the effect. It establishes > that a verified human approved these parameters, not that the approval > preceded the deferred issuance in any way a third party can check > later. That gap is real and is not closed by anything in this > construction. > > I have written the evidence side up as draft-yossif-psea, and the > requirements without a mechanism as > draft-yossif-agent-mandate-problem. Neither is a proposal for DTR and > I am not suggesting a change to the draft. The reason for raising it > here is narrower: Mitchell's observation that for a client serving > many principals the unit of authority is the individual delegation > rather than the client seems to me correct and more general than the > deferral case, and if it is correct then something has to carry > per-delegation state that the client cannot forge. The deferral window > is where that becomes unavoidable rather than optional, which is why > this thread surfaced it first. > > Mohamad Khalil-Yossif > > > > > _______________________________________________ > 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]
