On 3/2/23 3:51 PM, Vittorio Bertocci wrote:
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:
Why can't much of what you had to explain to Roman and then to me be put
in the draft?
I think you have pretty good datapoints that the draft doesn't
communicate your intent as you intend given those two points of feedback.
You can _acknowledge_ the questions and let designers/implementors know
what your general thinking was without trying to fully specify behavior.
- "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
