[GNAP] Re: Intdir early review of draft-ietf-gnap-resource-servers-05

[Justin Richer <[e-mail]>]

Hi Tommy, thanks for the review. Some comments inline.
— Justin

On Jun 18, 2024, at 8:01 PM, Tommy Pauly via Datatracker <[e-mail]> wrote:

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.

This document does not seek to define JWT again, but rather to map the concepts to existing JWT claims where possible, and define new JWT claims where they don’t exist. I’m not sure of a better way to do that than to point to JWT itself — we aren’t defining a new token format so much as mapping into an existing one.

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

This is just a call out to the GNAP Core spec, plus any extensions that might come along in the future. Basically, it doesn’t matter as much how you :get: the token for this statement.

- It would be useful to
add step-by-step instructions for generating and validating the tokens, with
concrete examples and test vectors if possible.

This is the purview of GNAP Core for tokens in general, and JWT for JWT-formatted tokens specifically.

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

The JWT claims are only for JWT tokens. If there’s another token format that wants to be defined, it would need to map the concepts from the token model into whatever claims structure

- 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"?

Security considerations should not have any normative requirements, so this is a declarative description of a needed requirement to be fulfilled. If this connection is happening over a trusted private network — such as a VLAN between containers inside a cluster, for example — TLS might not really be a reasonable requirement.


Nits:
Section 7.3: "Cacheing" -> "Caching"
Section 8.1: "Medial" -> "Medical"; this sentence is also not a complete
sentence.



Got it, thank you, we’ll fix!

 — Justin