[GNAP] Intdir early review of draft-ietf-gnap-resource-servers-05
Tommy Pauly via Datatracker <noreply@ietf.org> Wed, 19 June 2024 00:01 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF5C18DBB4; Tue, 18 Jun 2024 17:01:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tommy Pauly via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171875527668.3177.17110443481512457533@ietfa.amsl.com>
Date: Tue, 18 Jun 2024 17:01:16 -0700
Message-ID-Hash: I463DXUTLCPSQYFXMUHYZO44GVG7ZRQO
X-Message-ID-Hash: I463DXUTLCPSQYFXMUHYZO44GVG7ZRQO
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-gnap-resource-servers.all@ietf.org, txauth@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Tommy Pauly <tpauly@apple.com>
Subject: [GNAP] Intdir early review of draft-ietf-gnap-resource-servers-05
List-Id: GNAP <txauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9FvRNVj9m-Xevv1h4vt2TyKtxFs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Owner: <mailto:txauth-owner@ietf.org>
List-Post: <mailto:txauth@ietf.org>
List-Subscribe: <mailto:txauth-join@ietf.org>
List-Unsubscribe: <mailto:txauth-leave@ietf.org>
Reviewer: Tommy Pauly
Review result: On the Right Track
This is an early review on behalf of the Internet Area Directorate.
>From an INTDIR perspective, I don't see any particular issues — the document
doesn't discuss much at the Internet layer (no addressing, tunneling, etc).
However, I do think the document has some nits that can be improved, and
overall could be structured more clearly. Some points to consider: - Much of
Section 2.1 refers to a particular format of token (the "JWT-formatted token"),
but continually is just referencing the main JWT RFC instead of a reference for
the JWT token definition for this protocol. Having this link within the
document to the common/canonical JWT-formatted token would make things much
clearer, so the reader can see the full list of properties in their concrete
instantiation. You may even want to consider moving the concrete definition, or
an example of it, up to the top of Section 2 so readers can have an idea of the
scope of the token before reading the abstract field descriptions. Having
concrete examples for each field would be useful as well. - In Section 2.1.2,
it says "The access token is issued by the AS in a standard GNAP transaction".
Can we get a reference for this standard transaction? - It would be useful to
add step-by-step instructions for generating and validating the tokens, with
concrete examples and test vectors if possible. - The registry in Section 6.5
seems to match against the "JWT-formatted" token fields ("is conveyed in the
nbf claim of a [JWT] formatted token"). Do these apply outside of JWT?
Clarifying how things work for the non-JWT case, if that is supported, would be
good. - In the security considerations, why is TLS protection not a MUST
instead of a "have to"? Also, why give the exception where TLS is only required
on untrusted networks? Do we actually want to encourage insecure connections on
"trusted networks"?
Nits:
Section 7.3: "Cacheing" -> "Caching"
Section 8.1: "Medial" -> "Medical"; this sentence is also not a complete
sentence.
- [GNAP] Intdir early review of draft-ietf-gnap-res… Tommy Pauly via Datatracker
- [GNAP] Re: Intdir early review of draft-ietf-gnap… Justin Richer