Change:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine

Discussion:
communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another <del> chained RS as well as a client-facing discovery mechanism that can be used to bootstrap the GNAP process when the client instance does not know which AS protects a given RS. </del> <ins> chained RS. </ins> The means of the authorization server issuing the access token to the client instance and the means of the client instance presenting the

The AS responds with a handle appropriate to represent the resources list that the RS presented. <del> The RS MAY make this handle available as part of a rs-request- without-token or as documentation to developers. </del> <ins> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </ins> [[ See issue #117 [2] ]]

5. <del> 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 handle SHOULD be sufficient for at least the action the client instance was attempting to take at the RS.  The RS MAY use the rs-register-resource-handle to register a new resource handle, or use a handle that has been pre-configured to represent what the RS is protecting.  The content of this handle is opaque to the RS and the client instance in both cases. The client instance then makes a call to the "as_uri" as described in I-D.ietf-gnap-core-protocol, 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, and MAY request multiple access tokens. [[ See issue #118 [4] ]] 6. </del> [[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <del> 7. </del> <ins> 6. </ins> [[ TBD: There are a lot of security considerations to add. ]]

handles act as shared secrets, though they can be combined with a requirement to provide proof of a key as well. <del> 8. </del> <ins> 7. </ins> [[ TBD: There are a lot of privacy considerations to add. ]]

from an RS, this can be used to derive information about the resources being protected without releasing the resources themselves. <del> 9.  References </del> <ins> 8.  References </ins> <del> 9.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 <del> [4] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/118 </del>