[OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/



--
COMMENT:
--

Most of the SHOULDs here seem unsupported to me, in the sense that I'm not
clear what interoperability breaks if I decide not to do what it says.  Some
prose about that would be helpful to include.

I know this isn't the first OAUTH document I've reviewed, but I still find it
strange that claim names are not quoted or in all-caps or something.  In prose,
they just look like typos to me.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-step-up-authn-challenge-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/



--
COMMENT:
--

Thanks to Robert Sparks for the ARTART reviews and Mark Nottingham for the
HTTPDIR review.  Please make sure the former was fully addressed before
proceeding.

The SHOULD at the top of Section 4 is bare.  What happens if I don't do that? 
Or should this really be a MUST?

Same question for the first SHOULD in Section 5.  Is there ever a legitimate
reason not to do what it says?

I feel that claim names such as "acr" should be quoted.  They look like
misspelled words otherwise.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Paul Wouters' No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Michael Jones]

Thanks for reviewing the specification, Paul.

The authors agree it is too late in the game to change the name of "nonce".

FYI, I plan to dial into the telechat and listen in on mute, in case anyone 
wants to ask questions during the call.

Best wishes,
-- Mike

-Original Message-
From: OAuth  On Behalf Of Paul Wouters via Datatracker
Sent: Wednesday, April 12, 2023 6:07 PM
To: The IESG 
Cc: draft-ietf-oauth-d...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org
Subject: [OAUTH-WG] Paul Wouters' No Objection on draft-ietf-oauth-dpop-14: 
(with COMMENT)

Paul Wouters has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/



--
COMMENT:
--

Thanks for the clear specification.

While I agree with Ben Schwartz comment in the secdir review that the term
"nonce" is wrong in the document, and that it should really be called "cookie",
I think it is too late in the game to change this.



___
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

Re: [OAUTH-WG] [Ext] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

[Amanda Baber]

Hi Lars,

About this registration modification question (see [AB]):

--
DISCUSS:
--

# GEN AD review of draft-ietf-oauth-dpop-14

CC @larseggert

## Discuss

### Section 12.7.1, paragraph 3
```
 However, the initial registration of the nonce claim by [OpenID.Core]
 used language that was contextually specific to that application,
 which was potentially limiting to its general applicability.

 This specification therefore requests that the entry for nonce in the
 IANA "JSON Web Token Claims" registry [IANA.JWT] be updated as
 follows to reflect that the claim can be used appropriately in other
 contexts.
```
Is OpenID as the change controller OK with the IETF changing the IANA 
registry in this way?

[AB] Brian Campbell writes,

> The document authors are all members of, or co-chair, the OpenID WG that is
> the change controller for the registry. As such, we are comfortable
> representing that group in approval of the small modification to the
> registry entry for the "nonce" JWT claim.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Paul Wouters' No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-oauth-dpop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/



--
COMMENT:
--

Thanks for the clear specification.

While I agree with Ben Schwartz comment in the secdir review that the term
"nonce" is wrong in the document, and that it should really be called "cookie",
I think it is too late in the game to change this.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

[Brian Campbell]

Thank you, Lars, for the review and ballot. I put together this small PR
with updates for the comments/nits
https://github.com/oauth-wg/oauth-step-up-authn-challenge/pull/4

On Wed, Apr 12, 2023 at 5:18 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-oauth-step-up-authn-challenge-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/
>
>
>
> --
> COMMENT:
> --
>
> # GEN AD review of draft-ietf-oauth-step-up-authn-challenge-14
>
> CC @larseggert
>
> Thanks to Christer Holmberg for the General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-art/oLXp-vndky-rjnfs7kkHjH8acSg
> ).
>
> ## Comments
>
> ### Inclusive language
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term `traditional`; alternatives might be `classic`, `classical`,
> `common`,
>`conventional`, `customary`, `fixed`, `habitual`, `historic`,
>`long-established`, `popular`, `prescribed`, `regular`, `rooted`,
>`time-honored`, `universal`, `widely used`, `widespread`
>
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### URLs
>
> These URLs in the document can probably be converted to HTTPS:
>
>  * http://openid.net/specs/openid-connect-core-1_0.html
>
> ### Grammar/style
>
>  Section 2, paragraph 12
> ```
> hentication level, and the new one- selecting the appropriate token for
> each
>^^
> ```
> This word seems to be formatted incorrectly. Consider fixing the spacing or
> removing the hyphen completely.
>
>  Section 4, paragraph 1
> ```
>  Subsequent to the challenge in Figure 3, a cl
>  ^
> ```
> Consider using "after".
>
>  Section 5, paragraph 1
> ```
>  requirements, the resource servers needs a way of accessing information
> abou
> ^
> ```
> The verb form "needs" does not seem to match the subject "servers".
>
>  Section 6.2, paragraph 6
> ```
> ation server as a result of the requirements propagation method described
> he
> 
> ```
> An apostrophe may be missing.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
>
>
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [IANA #1270468] expert review for draft-ietf-oauth-dpop (oauth-parameters)

[Justin Richer]

Hi al — sorry, I missed these first couple emails entirely.

Yes, I have read the document and I approve this registration.

 — Justin

> On Apr 12, 2023, at 1:45 AM, Amanda Baber via RT 
>  wrote:
> 
> Hi Justin,
> 
> Can you review this OAuth Dynamic Client Registration Metadata request before 
> Thursday?
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-14#name-oauth-dynamic-client-regist
> 
> thanks,
> Amanda
> 
> On Mon Apr 10 20:08:46 2023, david.dong wrote:
>> Dear Justin,
>> 
>> Hello. Have you had a chance to review these proposed registrations?
>> 
>> The due date is Wednesday April 12th, 2023, as this document is on
>> this week's IESG telechat agenda.
>> 
>> Thank you very much for your time.
>> 
>> Best regards,
>> 
>> David Dong
>> IANA Services Specialist
>> 
>> On Thu Apr 06 15:22:17 2023, david.dong wrote:
>>> Dear Justin (cc: oauth WG),
>>> 
>>> As the designated expert for the OAuth Dynamic Client Registration
>>> Metadata registry, can you review the proposed registration in draft-
>>> ietf-oauth-dpop for us? Please see:
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>>> 
>>> The due date is Wednesday April 12th, 2023. This document is on next
>>> week's IESG telechat agenda.
>>> 
>>> -
>>> Eleventh, in the OAuth Dynamic Client Registration Metadata also on
>>> the OAuth Parameters registry page located at:
>>> 
>>> https://www.iana.org/assignments/oauth-parameters/
>>> 
>>> a single, new parameter is to be registered as follows:
>>> 
>>> Metadata Name: dpop_bound_access_tokens
>>> Metadata Description: Boolean value specifying whether the client
>>> always uses DPoP for token requests
>>> Change Controller: IETF
>>> Specification Document(s): [ RFC-to-be; Section 5.2 ]
>>> 
>>> As this section of the draft also requests registrations in a
>>> Specification Required (see RFC 8126) registry, the IESG-designated
>>> experts for the OAuth Dynamic Client Registration Metadata registry
>>> have asked that you send a review request to the mailing list
>>> specified in RFC7591. This review must be completed before the
>>> document's IANA state can be changed to "IANA OK."
>>> -
>>> 
>>> If this registration is OK, when the IESG approves the document for
>>> publication, we'll make the registration at:
>>> 
>>> https://www.iana.org/assignments/oauth-parameters/
>>> 
>>> With thanks,
>>> 
>>> David Dong
>>> IANA Services Specialist
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

[Brian Campbell]

The smaller comments/nits are addressed in this PR
https://github.com/danielfett/draft-dpop/pull/184/files

On Wed, Apr 12, 2023 at 6:52 AM Brian Campbell 
wrote:

> Thank you, Lars, for the review. I've endeavored to respond to your
> comments, especially the Discuss item, inline below. And I will soon make
> corresponding updates to the document source.
>
> On Wed, Apr 12, 2023 at 4:03 AM Lars Eggert via Datatracker <
> nore...@ietf.org> wrote:
>
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-oauth-dpop-14: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> # GEN AD review of draft-ietf-oauth-dpop-14
>>
>> CC @larseggert
>>
>> ## Discuss
>>
>> ### Section 12.7.1, paragraph 3
>> ```
>>  However, the initial registration of the nonce claim by [OpenID.Core]
>>  used language that was contextually specific to that application,
>>  which was potentially limiting to its general applicability.
>>
>>  This specification therefore requests that the entry for nonce in the
>>  IANA "JSON Web Token Claims" registry [IANA.JWT] be updated as
>>  follows to reflect that the claim can be used appropriately in other
>>  contexts.
>> ```
>> Is OpenID as the change controller OK with the IETF changing the IANA
>> registry in this way?
>>
>
> I believe so, yes. The authors of this draft are all members of (or
> co-chairs) the OpenID WG that is the change controller for the registry. As
> such, we are reasonably comfortable representing the rough consensus of
> that WG to give the OK to the registry update.
>
> Is there something more that needs to happen? Admittedly, I've not seen or
> done an update like this before so am not sure what all is supposed to be
> involved.
>
>
>
>>
>> --
>> COMMENT:
>> --
>>
>> ## Comments
>>
>> ### Section 9, paragraph 5
>> ```
>>  only at the issuing server.  Developers should also take care to not
>>  confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token
>>  nonce.
>> ```
>> Could this ambiguity not be avoided by using a different term/claim?
>>
>
> Despite that text being included, I'd argue that the likelihood of
> confusion is pretty low as they are different tokens in different contexts.
>
> There was some debate over the claim name (with pros and cons one both
> sides) but ultimately the rough consensus outcome of the WG was to
> use/reuse the "nonce" claim in the DPoP proof JWT as the draft currently
> has it.
>
>
> ### Too many authors
>>
>> The document has six authors, which exceeds the recommended author limit.
>> Has
>> the sponsoring AD agreed that this is appropriate?
>>
>
> Roman can correct me, if I'm wrong, but has said previously that he is OK
> with it.
>
>
>
> ### Missing references
>>
>> No reference entries found for these items, which were mentioned in the
>> text:
>> `[IANA.OAuth.Parameters]`.
>>
>
> Will fix.
>
>
>>
>> ### DOWNREFs
>>
>> DOWNREF `[RFC8792]` from this Proposed Standard to Informational
>> `RFC8792`.
>> (For IESG discussion. It seems this DOWNREF was not mentioned in the Last
>> Call
>> and also seems to not appear in the DOWNREF registry.)
>>
>
> I believe RFC8792 should have been an Informative Reference. I'll update.
>
>
>>
>> ### Inclusive language
>>
>> Found terminology that should be reviewed for inclusivity; see
>> https://www.rfc-editor.org/part2/#inclusive_language for background and
>> more
>> guidance:
>>
>>  * Term `native`; alternatives might be `built-in`, `fundamental`,
>> `ingrained`,
>>`intrinsic`, `original`
>>  * Term `blindly`; alternatives might be `visually impaired`, `unmindful
>> of`,
>>`unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
>>`unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`
>>
>
> I'll look to update with alternatives or omit the words.
>
>
>>
>> ## Nits
>>
>> All comments below are about very minor potential issues that you may
>> choose to
>> address in some way - or ignore - as you see fit. Some were flagged by
>> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
>> there
>> will likely be some false positives. There is no need to let me know what
>> you
>> did with these suggestions.
>>
>>
>> ### JSON
>>

Re: [OAUTH-WG] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

[Brian Campbell]

Thank you, Lars, for the review. I've endeavored to respond to your
comments, especially the Discuss item, inline below. And I will soon make
corresponding updates to the document source.

On Wed, Apr 12, 2023 at 4:03 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-oauth-dpop-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
>
>
> --
> DISCUSS:
> --
>
> # GEN AD review of draft-ietf-oauth-dpop-14
>
> CC @larseggert
>
> ## Discuss
>
> ### Section 12.7.1, paragraph 3
> ```
>  However, the initial registration of the nonce claim by [OpenID.Core]
>  used language that was contextually specific to that application,
>  which was potentially limiting to its general applicability.
>
>  This specification therefore requests that the entry for nonce in the
>  IANA "JSON Web Token Claims" registry [IANA.JWT] be updated as
>  follows to reflect that the claim can be used appropriately in other
>  contexts.
> ```
> Is OpenID as the change controller OK with the IETF changing the IANA
> registry in this way?
>

I believe so, yes. The authors of this draft are all members of (or
co-chairs) the OpenID WG that is the change controller for the registry. As
such, we are reasonably comfortable representing the rough consensus of
that WG to give the OK to the registry update.

Is there something more that needs to happen? Admittedly, I've not seen or
done an update like this before so am not sure what all is supposed to be
involved.



>
> --
> COMMENT:
> --
>
> ## Comments
>
> ### Section 9, paragraph 5
> ```
>  only at the issuing server.  Developers should also take care to not
>  confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token
>  nonce.
> ```
> Could this ambiguity not be avoided by using a different term/claim?
>

Despite that text being included, I'd argue that the likelihood of
confusion is pretty low as they are different tokens in different contexts.

There was some debate over the claim name (with pros and cons one both
sides) but ultimately the rough consensus outcome of the WG was to
use/reuse the "nonce" claim in the DPoP proof JWT as the draft currently
has it.


### Too many authors
>
> The document has six authors, which exceeds the recommended author limit.
> Has
> the sponsoring AD agreed that this is appropriate?
>

Roman can correct me, if I'm wrong, but has said previously that he is OK
with it.



### Missing references
>
> No reference entries found for these items, which were mentioned in the
> text:
> `[IANA.OAuth.Parameters]`.
>

Will fix.


>
> ### DOWNREFs
>
> DOWNREF `[RFC8792]` from this Proposed Standard to Informational `RFC8792`.
> (For IESG discussion. It seems this DOWNREF was not mentioned in the Last
> Call
> and also seems to not appear in the DOWNREF registry.)
>

I believe RFC8792 should have been an Informative Reference. I'll update.


>
> ### Inclusive language
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term `native`; alternatives might be `built-in`, `fundamental`,
> `ingrained`,
>`intrinsic`, `original`
>  * Term `blindly`; alternatives might be `visually impaired`, `unmindful
> of`,
>`unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
>`unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`
>

I'll look to update with alternatives or omit the words.


>
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
>
> ### JSON
>
> ```
>
> {
>  "error": "use_dpop_nonce"
>  ^ Expecting ',' delimiter
>  "error_description":
> }```
>
>
Will fix.



> ### Outdated references
>
> Document references `draft-ietf-oauth-security-topics-21`, but `-22` is the
> latest available revision.
>

Okay.


>
> ### URLs
>
> These URLs in the document can probably be 

Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

[Lars Eggert]

Christer, thank you for your review. I entered a No Objection ballot.

Lars

> On 23. Feb 2023, at 19:13, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-oauth-step-up-authn-challenge-11
> Reviewer: Christer Holmberg
> Review Date: 2023-02-23
> IETF LC End Date: 2023-03-03
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is well written, and easy to read. However, I have found
> some issues that I would like the authors to address.
> 
> Major issues:
> 
>  QMa1: General
> 
>As the document defines a new error code, and define new WWW-Authenticate
>parameters, should the document not be an Update to RFC 6750?
> 
> 
> 
>  QMa2: Section 4
> 
>The text defines the procedures for the client.
> 
>But, what if the client does not support the new error code and the new
>WWW-A parameters? I think there should be some backward compatibility text
>(or reference, if defined elsewhere).
> 
>Especially it should be clear that the server will not receive the WWW-A
>parameters in the new request if the client does not support them.
> 
> 
> 
> Minor issues:
> 
>  QMi1: Section 3
> 
>Can the new WWW-Authenticate parameters only be used with the new error
>code? If so, please indicate it.
> 
> ---
> 
>  QMi2: Section 3
> 
>Is the max_age value required to be given as a string value (as in the
>example)? If so, please indicate it.
> 
> ---
> 
> Nits/editorial comments:
> 
>  QNi1: General
> 
>Throughout the document uses "doesn't", "isn't" and "it's". I suggest
>replacing those with "does not", "is not" and "it is".
> 
> 
> 
>  QNi2: Abstract
> 
>The text starts by talking about resource servers, requests etc. Eventhough
>the document title mentions OAuth 2.0, I think it would also be good to
>mention it in the beginning of the Abstract.
> 
>E.g.,
> 
>"When OAuth 2.0 is used, it is not uncommon for..."
> 
> 
> 
>  QNi3: Introduction
> 
>Similar to the Abstract, I think it would be good to mention OAuth 2.0 in
>the beginning.
> 
>Also, I am not sure what "API authorization scenario" means.
> 
>Could you say "OAuth 2.0 authorization scenario"?
> 
> 
> 
>  QNi4: Introduction
> 
>The text says: "An API might also determine"
> 
>Should it say "authorization server" instead of "API"?
> 
> 
> 
> -- 
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-oauth-step-up-authn-challenge-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/



--
COMMENT:
--

# GEN AD review of draft-ietf-oauth-step-up-authn-challenge-14

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/oLXp-vndky-rjnfs7kkHjH8acSg).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://openid.net/specs/openid-connect-core-1_0.html

### Grammar/style

 Section 2, paragraph 12
```
hentication level, and the new one- selecting the appropriate token for each
   ^^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

 Section 4, paragraph 1
```
 Subsequent to the challenge in Figure 3, a cl
 ^
```
Consider using "after".

 Section 5, paragraph 1
```
 requirements, the resource servers needs a way of accessing information abou
^
```
The verb form "needs" does not seem to match the subject "servers".

 Section 6.2, paragraph 6
```
ation server as a result of the requirements propagation method described he

```
An apostrophe may be missing.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Lars Eggert's Discuss on draft-ietf-oauth-dpop-14: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-oauth-dpop-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/



--
DISCUSS:
--

# GEN AD review of draft-ietf-oauth-dpop-14

CC @larseggert

## Discuss

### Section 12.7.1, paragraph 3
```
 However, the initial registration of the nonce claim by [OpenID.Core]
 used language that was contextually specific to that application,
 which was potentially limiting to its general applicability.

 This specification therefore requests that the entry for nonce in the
 IANA "JSON Web Token Claims" registry [IANA.JWT] be updated as
 follows to reflect that the claim can be used appropriately in other
 contexts.
```
Is OpenID as the change controller OK with the IETF changing the IANA registry 
in this way?


--
COMMENT:
--

## Comments

### Section 9, paragraph 5
```
 only at the issuing server.  Developers should also take care to not
 confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token
 nonce.
```
Could this ambiguity not be avoided by using a different term/claim?

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[IANA.OAuth.Parameters]`.

### DOWNREFs

DOWNREF `[RFC8792]` from this Proposed Standard to Informational `RFC8792`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`
 * Term `blindly`; alternatives might be `visually impaired`, `unmindful of`,
   `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
   `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.


### JSON

```

{
 "error": "use_dpop_nonce"
 ^ Expecting ',' delimiter
 "error_description":
}```

### Outdated references

Document references `draft-ietf-oauth-security-topics-21`, but `-22` is the
latest available revision.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://www.iana.org/assignments/jwt
 * http://openid.net/specs/openid-connect-core-1_0.html

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth