[OAUTH-WG] Re: Comments on draft-gerber-oauth-deferred-token-response: delegation verifiability during the pending window

[Mohamad Khalil Yossif <[e-mail]>]

> 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