Change:
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

Discussion:
: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