Telechat Review of draft-ietf-oauth-step-up-authn-challenge-13
review-ietf-oauth-step-up-authn-challenge-13-httpdir-telechat-nottingham-2023-04-04-00
Request | Review of | draft-ietf-oauth-step-up-authn-challenge |
---|---|---|
Requested revision | No specific revision (document currently at 17) | |
Type | Telechat Review | |
Team | HTTP Directorate (httpdir) | |
Deadline | 2023-04-11 | |
Requested | 2023-03-15 | |
Authors | Vittorio Bertocci , Brian Campbell | |
I-D last updated | 2023-04-04 | |
Completed reviews |
Secdir Last Call review of -12
by Valery Smyslov
(diff)
Artart Last Call review of -12 by Robert Sparks (diff) Genart Last Call review of -11 by Christer Holmberg (diff) Artart Telechat review of -13 by Robert Sparks (diff) Httpdir Telechat review of -13 by Mark Nottingham (diff) |
|
Assignment | Reviewer | Mark Nottingham |
State | Completed | |
Request | Telechat review on draft-ietf-oauth-step-up-authn-challenge by HTTP Directorate Assigned | |
Reviewed revision | 13 (document currently at 17) | |
Result | Not ready | |
Completed | 2023-04-04 |
review-ietf-oauth-step-up-authn-challenge-13-httpdir-telechat-nottingham-2023-04-04-00
# 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.