Re: [art] [OAUTH-WG] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12

[Robert Sparks <[e-mail]>]

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 
> <[e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>