Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

Hi Mark, thanks for the review.

On the terminology nits, I wanted to add some context.

"Resource server" is a term used throughout the OAuth specs, defined in
RFC6749. The term "resource" is used to distinguish the resource server
from the authorization server. It would be incredibly confusing and
ambiguous to refer to this only as the "server".

Again, the term "resource request" uses "resource" to distinguish this
request from the "authorization request" that the client makes.

The term "protected resource" is also defined in RFC 6749, which is why
it's used in this draft.

Many of the other OAuth extensions also use these terms, and usually have a
section in the introduction that mention these terms come from RFC 6749. (
https://www.rfc-editor.org/rfc/rfc9207#section-1.1
https://www.rfc-editor.org/rfc/rfc9068#section-1.2) I believe it would be a
good idea to add this paragraph to this draft as well for clarity.

On the WWW-Authenticate header, this draft is extending RFC6750's use of
the WWW-Authenticate header, not trying to extend HTTP's definition of it.
Thanks for the reference to RFC9110 though because I just checked the
in-progress OAuth 2.1 draft (which updates RFC6750) and it still references
the older RFC7235, so I will go update that to reference RFC9110 instead.

Thanks,

---
Aaron Parecki


On Tue, Apr 4, 2023 at 10:19 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.
>
> ### 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.
>
> ## 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.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>