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

[Lars Eggert]

Hi,

On 13. Apr 2023, at 04:53, Amanda Baber  wrote:
>> 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.

if that's the case, and we now have it on record via his email, I consider my 
DISCUSS resolved.

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

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

[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Lars Eggert via Datatracker]

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

Re: [OAUTH-WG] [Last-Call] [Gen-art] Genart last call review of draft-ietf-oauth-rar-15

[Lars Eggert]

Robert, thank you for your review and thank you all for the following 
discussion. I have entered a No Objection ballot for this document.

Lars


> On Nov 18, 2022, at 00:45, Robert Sparks  wrote:
> 
> 
> On 11/17/22 4:44 PM, Robert Sparks wrote:
>> Apologies - an upload fumble left -00 empty. I've revised it to have content 
>> at -01.
> 
> Which I'll also paste here for convenience:
> 
> 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-rar-14 (<- that was a typo - I really did review 
> 15)
> Reviewer: Robert Sparks
> Review Date: 2022-11-17
> IETF LC End Date: 2022-11-17
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues: Essentially ready for publication as a Proposed Standard RFC, 
> but with issues to discuss before publication
> 
> I have two major issues that I think need discussion:
> 
> Major Issue 1) The document seems to be specifying a new way of comparing 
> json names, claiming it is what RFC8259 requires, but I disagree that RFC8259 
> says what this document is claiming. If I'm correct, the document is trying 
> to rely on the text in section 7 of RFC8259 to support the idea that 
> implementation MUST NOT alter the json names (such as applying Unicode 
> normalization) before comparison and that the comparison MUST be performed 
> octet-by-octet. Rather, section 7 says something more like "you better escape 
> and unescape stuff correctly if you’re going to do unicode codepoint by 
> codepoint comparison" which is a completely different statement.
> 
> If I'm right, and this is a new comparison rule that goes beyond what JSON 
> itself defines, I think the group should seek extra guidance from Unicode 
> experts. If I'm wrong and this behavior is defined somewhere else, please 
> provide a better pointer to the definition.
> 
> In many environments, its unusual for an implementation relying on a stack 
> below it to have any say at all on whether normalization is going to be 
> applied to the unicode before the application gets to look. Rather than 
> trying to work around the problem you've identified with normalization by 
> specifying the comparison algorithm, consider just making stronger statements 
> about the strings used in the json names the document defines. Why _can't_ 
> you restrict the authorization_details values to ascii? If it's because you 
> want to present the string to a user, consider putting a presentation string 
> elsewhere in the json that is not used for comparison.
> 
> Major Issue 2) The suggested pattern demonstrated starting in figure 16 
> (using [] to mean "let the user choose") seems underspecified. If the point 
> is that different APIs may invent different mechanics _like_ this, and that 
> this is only an example. Make it much clearer that this is an example. If 
> this is a pattern you expect all APIs to follow, then more description is 
> warranted. Is it intended that a user could add and remove things arbitrarily 
> to such lists? For instance is it intended that this support an interaction 
> where the client is asking for permission to operate on account A, and the 
> user can say "no, but you can operate on account B"?
> 
> Minor issues:
> 
> Section 2: What does "The AS MUST ensure that there is no collision between 
> different authorization details types that it supports." mean? How is this a 
> 2119 requirement? I _think_ you're trying to point out that the 
> authorization_details string is a unique-key at any AS and that that has 
> consequences on the API _designer_, but I don't know what is expected of an 
> AS coder here. Some clearer words are needed.
> 
> Section 7: Please expand on, or rephrase, "if these are deemed of no intended 
> use for the client." Could you just delete the phrase? If you are only 
> explaining why an AS might do this, make it clear that it's an example (and 
> split the example into a separate sentence). If this is the _only_ reason an 
> AS might omit values in the token Response, then more detail is needed.
> 
> 
> Nits/editorial comments:
> 
> Throughout the document, there is a mix of "authorization_details" and 
> "authorization details". It is not completely consistent using one when 
> talking about the parameter and the other when talking about the general 
> concept of details about authorization. Please inspect each occurrence and 
> verify that it is using the correct form.
> 
> Introduction: suggest changing 'defines the parameter scope' to 'defines the 
> parameter "scope"'
> 
> Introduction just after figure 1 - expand AS (first use).
> 
> Section 2.2: Please rework the sentence where you mention "the cartesian 
> product" and remove the 

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

[Lars Eggert]

Hi,

On 2022-6-2, at 10:09, Lars Eggert  wrote:
> This looks like a tooling issue.

I opened https://github.com/ietf-tools/datatracker/issues/4048

Thanks,
Lars




signature.asc
Description: Message signed with OpenPGP
___
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-jwk-thumbprint-uri-02: (with COMMENT)

[Lars Eggert]

Hi,

On 2022-6-2, at 5:22, Kristina Yasuda  wrote:
> Regarding your reference to the Simplified BSD License, could you please 
> clarify what you meant since 
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-02.html 
> does refer to the Revised BSD License? There doesn't seem to be a problem in 
> that regard.

I reviewed the text version at 
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-02.txt and 
that does refer to the simplified BSD license. (Same for -03.)

This looks like a tooling issue. Did you submit XML (only) to the datatracker 
when you submitted -03?

Thanks,
Lars



signature.asc
Description: Message signed with OpenPGP
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-jwk-thumbprint-uri-01

[Lars Eggert]

Robert, thank you for your review. I have entered a No Objection ballot for 
this document.

Lars


> On 2022-5-3, at 22:53, Robert Sparks via Datatracker  wrote:
> 
> Reviewer: Robert Sparks
> Review result: Ready
> 
> 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-jwk-thumbprint-uri-01
> Reviewer: Robert Sparks
> Review Date: 2022-05-03
> IETF LC End Date: 2022-05-09
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready for publication as a Proposed Standard RFC
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
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 via Datatracker]

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 via Datatracker]

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

Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-jwsreq-30

[Lars Eggert]

Joel, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2020-9-24, at 23:00, Joel Halpern via Datatracker  wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> 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-jwsreq-30
> Reviewer: Joel Halpern
> Review Date: 2020-09-24
> IETF LC End Date: 2020-10-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as a Proposed Standard
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments:  N/A
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Last-Call] Genart last call review of draft-ietf-oauth-access-token-jwt-11

[Lars Eggert]

Roni, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2021-2-7, at 11:28, Roni Even via Datatracker  wrote:
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> 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-access-token-jwt-??
> Reviewer: Roni Even
> Review Date: 2021-02-07
> IETF LC End Date: 2021-02-09
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is ready for publication as a standard track RFC with nit
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> In section 3 the get example has client_id as s6BhdRkqt3 and the claims has 
> s6BhdRkqt3_
> 
> 
> 
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
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 via Datatracker]

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