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

Lars Eggert via Datatracker <noreply@ietf.org> Tue, 06 April 2021 12:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3138B3A1F07; Tue, 6 Apr 2021 05:19:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Hannes.Tschofenig@gmx.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <161771156410.10254.11880146751203807355@ietfa.amsl.com>
Date: Tue, 06 Apr 2021 05:19:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/P8iTcOWO_L0QrbR-8J0MRIXQ8ys>
Subject: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2021 12:19:25 -0000

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:


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
+                                          ++++++++++