Re: Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

Thanks Mark. And thank you again for your review, which will improve the
document. We'll we merge the and publish an updated draft soon
incorporating your suggestions.


On Wed, Apr 5, 2023 at 5:44 PM Mark Nottingham <mnot@mnot.net> wrote:

> Thanks -- that looks good.
>
> Cheers,
>
>
> On 6 Apr 2023, at 5:31 am, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
> And that PR is here
> https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/3/files
>
> On Wed, Apr 5, 2023 at 10:59 AM Brian Campbell <bcampbell@pingidentity.com>
> wrote:
> Thank you for the review Mark. I've replied inline below with some context
> or explanation as best I can. And I'll put together a PR with corresponding
> changes/clarifications.
>
> On Tue, Apr 4, 2023 at 11:18 PM Mark Nottingham via Datatracker <
> noreply@ietf.org> wrote:
> Reviewer: Mark Nottingham
> Review result: Not Ready
>
> # HTTPDIR review of drat-ietf-oauth-step-up-authn-challenge-13
>
> I am an assigned HTTP directorate reviewer for
> draft-ietf-masque-connect-ip.
> These comments were written primarily for the benefit of the ART Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the HTTP Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
>
> I've entered a 'not ready' position because of the first issue below; the
> remaining are relatively easy to address.
>
> ## Comments
>
> ### Global HTTP Authentication Parameters
>
> This draft seems to modify the HTTP authentication mechanism globally,
> regardless of the scheme in use. For example:
>
> "This specification introduces a new error code value for the error
> parameter
> of [RFC6750] or authentication schemes, such as [I-D.ietf-oauth-dpop],
> which
> use the error parameter"
>
> [...]
>
> "Furthermore, this specification defines additional WWW-Authenticate
> auth-param
> values to convey the authentication requirements back to the client."
>
> [...]
>
> "A client receiving an authorization error from the resource server
> carrying
> the error code insufficient_user_authentication SHOULD parse the
> WWW-Authenticate header for acr_values and max_age and use them, if
> present, in
> constructing an authorization request"
>
> If that is the intent, you need to update RFC9110 (which is likely to be
> contentious); otherwise, you need to scope it in such a way that
> authentication
> schemes 'opt into' their use.
>
> The intent is definitely not to globally modify the HTTP authentication
> mechanism. Rather the intent is to provide a new error code and two new
> parameters for the "Bearer" authentication scheme challenge from RFC6750
> (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params).
>
>
>
> ### Header Definition
>
> "This document also introduces acr_values and max_age parameters for the
> WWW-Authenticate response header defined by [RFC6750]"
>
> RFC6750 does not define WWW-Authenticate; RFC9110 does.
>
> Yeah, that was sloppy language. Apologies. The parameters are introduced
> for the Bearer authentication scheme challenge defined by [RFC6750] not the
> WWW-Authenticate response header in general.
>
>
> ## Nits
>
> I found the terminology in this draft confused, and confusing. E.g.,
>
> * Use of the term 'resource server' throughout is very jarring -- on the
> Web,
> it's just a 'resource'. The 'server' is responsible for the resource; if
> you
> mean the server, say 'server'; if you mean the resource, say 'resource'.
> Don't
> combine them.
>
> * Likewise, 'resource request' is redundant; every request is for a
> resource.
> Just say 'request'.
>
> * Similarly, the diagram on page 4 shows a 'resource server' returning a
> 'protected resource'. Resources are never transferred over the network;
> they
> send representations in responses -- one of those terms should be used.
>
> As Aaron mentioned in his reply to this thread - these terms are defined
> in RFC6749 and used throughout the OAuth family of specs providing useful
> context and disambiguation for OAuth roles and functionality etc. I agree
> with Aaron about adding a terminology paragraph to the draft to make it
> more explicit.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
>
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._