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 <noreply@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
