Hi Robert, thanks for your comments! Some of the ideas you mention here were also touched upon during the AD review w Roman, the exchange we had might provide some context https://mailarchive.ietf.org/arch/msg/oauth/PBDCtVB7vtou5Dlz6nPJxX_5Yyo/ but more succinctly:
- "step down". One of the key reasons this spec exists is that the RS, and only the RS, is the arbiter of what's good enough for a request at a given moment. The exact same API call and exact same token that worked few seconds earlier (and still meets the requirements of a preceding challenge, including max_age) could be rejected later, and trigger a completely different set of requirements, for example as the result of black box logic executed by an anomaly detection engine on the API side. Neither the client nor the AS can know in advance whether a particular token will work again, all they can do is caching tokens according to the call circumstances they know (URL, call parameters etc) and hope it will work again, while remaining ready to receive and process a new challenge if it doesn't. - Caching. Please see the discussion with Roman in the referenced thread, it should address the question. - Nit: we'll remove the ref from the doc history on the next update :) thanks V. On Thu, Mar 2, 2023 at 10:42 AM Robert Sparks via Datatracker < nore...@ietf.org> wrote: > > This message originated outside your organization. > > > Reviewer: Robert Sparks > Review result: Ready with Issues > > Summary: essentially ready but with issues to consider before being > published > as a proposed standard RFC. > > Issues: > > I expected to find some discussion of considerations of avoiding "step > down" > given the intuitive appeal to "step up". Can the client or Authorization > server > notice if the resource server has through whatever fault asserted that it > will > only accept the use of an authentication context class that is blatantly > inferior to what has already been provided? And if they notice, what is > expected to happen? Or is it expected that this is allowed, particularly > when a > short max_age is also supplied? > > The document also suggests that the client hold on to, and possibly re-use > in > the future, access tokens that have been challenged as having insufficient > user > authorization. Is this behavior something that follows a well-known and > well-implemented pattern documented elsewhere? If so, a pointer would be > useful. If not, this seems like something that deserves more discussion if > not > more definition. > > Nits: > The reference to abr-twitter-reply will go away with the changelog when > the RFC > Editor removes it. It would be kind to acknowledge that in the note to the > RFC > Editor so that they know it's expected and don't have to ask. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
