> 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]
