[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)
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 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
[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)
Lars Eggert has entered the following ballot position for draft-ietf-oauth-rar-18: 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-rar/ -- COMMENT: -- # GEN AD review of draft-ietf-oauth-rar-18 CC @larseggert Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/shFcI11Wajhydi8wJuFM3VaVfkI). ## 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: * Terms `her` and `his`; alternatives might be `they`, `them`, `their` ## 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 did not return content: * https://taxservice.govehub.no * http://hl7.org/fhir/organization-type * http://example.info/claims/groups I guess these are supposed to be example URLs. Please use the designated example domain names for this. ### Grammar/style Section 2.1, paragraph 1 ``` fication does not require the use of any of these common fields by an API def ^ ``` Consider simply using "of" instead. Section 3, paragraph 6 ``` if any of the following are true of any of the objects in authorization_deta ^ ``` Consider simply using "of" instead. Section 3, paragraph 10 ``` ke security decisions based on whether or not the request is asking for "mor ^^ ``` Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Section 7, paragraph 6 ``` Token Error Response MUST conform the the rules given in Section 5. 9. Reso ^^^ ``` Possible typo: you repeated a word. Section 16, paragraph 7 ``` * tax_payer_id: identifier of the tax payer (if known to the client) A.4. eH ^ ``` This word is normally spelled as one. ## 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 No Objection on draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)
Lars Eggert has entered the following ballot position for draft-ietf-oauth-jwk-thumbprint-uri-02: 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-jwk-thumbprint-uri/ -- COMMENT: -- # GEN AD review of draft-ietf-oauth-jwk-thumbprint-uri-02 CC @larseggert Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/OUPrqEJ7DNFPcaL9Goc7-7rZy_4). ## 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 `invalid`; alternatives might be `not valid`, `unenforceable`, `not binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`, `unacceptable`, `inapplicable`, `revoked`, `rescinded` ## 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. ### Boilerplate Document still refers to the "Simplified BSD License", which was corrected in the TLP on September 21, 2021. It should instead refer to the "Revised BSD License". ## 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 No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)
Lars Eggert has entered the following ballot position for draft-ietf-oauth-iss-auth-resp-03: 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/blog/handling-iesg-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-iss-auth-resp/ -- COMMENT: -- 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. Section 2.3. , paragraph 2, nit: > s by any other mechanism which is outside of the scope of this specification. > ^^ This phrase is redundant. Consider using "outside". Section 4. , paragraph 4, nit: > f alternative countermeasures are outside of the scope of this specification. > ^^ This phrase is redundant. Consider using "outside". These URLs in the document can probably be converted to HTTPS: * http://arxiv.org/abs/1508.04324 * http://www.iana.org/assignments/oauth-parameters * http://openid.net/specs/openid-connect-core-1_0.html ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)
Lars Eggert has entered the following ballot position for draft-ietf-oauth-jwsreq-32: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ -- COMMENT: -- Section 5.2, paragraph 5, comment: >The entire Request URI MUST NOT exceed 512 ASCII characters. There >are three reasons for this restriction. > >1. Many phones in the market as of this writing still do not accept >large payloads. The restriction is typically either 512 or 1024 >ASCII characters. > >2. On a slow connection such as 2G mobile connection, a large URL >would cause the slow response and therefore the use of such is >not advisable from the user experience point of view. What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to transmit; it's not clear that larger payloads would therefore be so much worse, given that the 2G latencies are probably the overriding issue here. Would a SHOULD NOT suffice? --- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4, paragraph 10, nit: -Signing it with the "RS256" algorithm results in this Request Object +Signing it with the "RS256" algorithm [RFC7518] results in this Request Object + ++ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
