Thanks for your review, Lars. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments.
Responses are inline below, prefixed by "Mike>". -----Original Message----- From: Lars Eggert via Datatracker <nore...@ietf.org> Sent: Tuesday, April 6, 2021 5:19 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; hannes.tschofe...@gmx.net Subject: 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? Mike> Changed "three" to "two". 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? Mike> This is now a SHOULD. ------------------------------------------------------------------------------- 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 + ++++++++++ Mike> I added the missing reference. Thanks again! -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
