Grant Negotiation and Authorization Protocol
draft-ietf-gnap-core-protocol-20

# Internet AD comments for draft-ietf-gnap-core-protocol-18
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1.2

* "which the absolute" -> "which is the absolute", I think

### S13.9

* "able capture of" -> "able to capture", I think

Thank you for addressing my (Orie's) DISCUSS.

===

My own review isn't done yet, but forwarding some comments from Orie Steele, incoming ART Area Director:

"""
The AS is uniquely defined by the grant endpoint URI, which the absolute URI where grant requests are started by clients.
"""

Suggested change "which is the absolute URI" (missing is?).

"""
Grant:

 (verb): to permit an instance of client software to receive some attributes at a specific time and valid for a specific duration and/or to exercise some set of delegated rights to access a protected resource;
 
 (noun): the act of granting permission to a client instance.

"""

I wonder if these definitions can be shortened to the following without loss of generality?

"""
Grant:
 (verb): to permit an instance of client software to receive attributes or to access protected resources.
 (noun): an expression of attributes or permissions given to an instance of client software.
"""
...
"""
Some promises can be conditional of some previous interactions (e.g. repeated requests).
"""

Suggested change: Some promises can be conditioned on previous interactions (e.g. repeated requests).

"""
In may cases, this happens through a front-channel interaction through the end user's browser.
"""

Suggested change: In many cases,...

In section-2.1.1

"""
A unique name chosen by the client instance to refer to the resulting access token.
"""

Is this meant to be a machine facing string, or a human facing one?
Are there unicode consideration that apply to this field, similar to https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-sfbis-05#section-3.3.8 ?

Put another way, is deceptive text a security consideration for this field?

"""
Each object is a subject identifier as defined by [[I-D.ietf-secevent-subject-identifiers](https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-18)].
"""

Suggest to update reference to: https://datatracker.ietf.org/doc/html/rfc9493


"""
If the identified end user does not match the RO present at the AS during an interaction step, and the AS is not explicitly allowing a cross-user authorization, the AS SHOULD reject the request with an unknown_user error.
"""

Why not MUST?

Section 2.5.3.1 Indicate Desired Interaction Locales

It would have been good to have gotten an i18n review based on this section.

I recommend a reference to https://datatracker.ietf.org/doc/html/rfc5895 regarding international domain names, to ensure that language considerations in URLs are also addressed.

In section 3, an informative or normative reference for DID should be provided.

In section 3.4


"""
value (string):
The assertion value as the JSON string serialization of the assertion. REQUIRED.
"""

The example starts with "eyj...", is this value meant to also be base64url encoded?

It seems like this might also be a JWT, in which case, its not a JSON string, its a string of base64url encoded JSON strings separated by periods.

A less elided example might be helpful here.

Section 4.1.2 rightly warns of deceptive / indistinguishable unicode, you might consider a citation to https://datatracker.ietf.org/doc/rfc8264/

Section 5.3

"""
  The AS SHOULD check that this presented user information is
   consistent with any user information previously presented by the
   client instance or otherwise associated with this grant request.
 """
 
 What happens if this check is not performed or the information does not match?
 
 References to ietf-httpbis-message-signatures should be updated to https://datatracker.ietf.org/doc/html/rfc9421
 
 In section 7.3.3
 
 +jwsd is introduced, but there is no corrosponding registered Structured Syntax Suffixes in https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml or in the document.
 
 Similarly  `typ: gnap-binding+...` implies a registered media type of `application/gnap-binding+...`

`gnap-binding-rotation` is also present but not requested to be registered via IANA media types registry.

In section 11, you may wish to comment on if expired drafts are acceptable references for specification required, so that experts have guidance on this topic.

In 11, I wonder if it is truly necessary to request 16 registries from IANA, given the initial entries for some of the registries contain only a single reference.