Original text:
GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles.  The focus of this protocol is to provide interoperability between the different parties acting in each role, and is not to specify implementation details of each.  Where appropriate, GNAP may make described in response-token-single. When neither an access token nor key proof are used, this is an <del> unsecured request.  This type of request is not used in the core protocol of GNAP. </del>  7.1. AS will deny a request from that client instance using a different proofing mechanism.  10. [[ TBD: There are a lot of items in the document that are expandable

Reviewer comments:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 3259334e2eec3bc29ead34a917ce3a579ca3cfe5 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
client requests to RS w/o access token should be covered in core (client-facing protocol) See also
Requesting a Resource With Insufficient Access: Editor's note: This borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol.
I'm in favour of this being in the core protocol. I don't think it adds that much complexity and it opens up a whole world of different deployment options.
First, the sentence at the top of this section is broken: . Second, I think this is a complicated decision: The RC is more likely to assume it will receive a useful response if this is in the core document rather than an extension. There may be privacy issues with the RS reporting the AS URI for a particular resource. Which would argue against including it in the core protocol.
It is definitely something that would be hard to make "mandatory to implement". I would like to see it included but not mandated for all deployments.
Yaron: 3.4: "updated_at": Unix time is nice, but for absolute time it's common to use ISO 8601 format. Justin: I stole this field from OIDC, but I’m fine with any format here, so if there’s no outcry we should change it in the next revision.
This has been changed to ISO 8601 format in 7d6c4580a11f2cd352d67121c8eeb68326b3d009

Revised text:
GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. <ins> This specification focuses on the portions of the delegation process facing the client instance.  In particular, this specification defines interoperable methods for a client instance to request, negotiate, and receive access to information facilitated by the authorization server.  This specification also discusses discovery mechanisms for the client instance to configure itself dynamically. The means for an authorization server and resource server to interoperate are discussed in the companion document, I-D.draft-ietf- gnap-resource-servers. </ins> The focus of this protocol is to provide interoperability between the different parties acting in each role, and is not to specify implementation details of each.  Where appropriate, GNAP may make described in response-token-single. When neither an access token nor key proof are used, this is an  <ins> unsecured request.  This type of request is used optionally for calls to the RS as part of an RS-first discovery process as described in rs-request-without-token. </ins> 7.1. AS will deny a request from that client instance using a different proofing mechanism. <ins> 9.1. If the client instance calls an RS without an access token, or with an invalid access token, the RS MAY respond to the client instance with an authentication header indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance MAY use in its access token request.  This resource reference MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource- servers.  The content of the resource handle is opaque to the client instance. The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the "access" array in the "access_token" portion of the request.  The client instance MAY request additional resources and other information.  The client instance MAY request multiple access tokens. In this non-normative example, the client instance is requesting a single access token using the resource reference "FWWIKYBQ6U56NL1" received from the RS in addition to the "dolphin-metadata" resource reference that the client instance has been configured with out of band. If issued, the resulting access token would contain sufficient access to be used at both referenced resources. </ins> 10. [[ TBD: There are a lot of items in the document that are expandable