Original text:
The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields: <del> OPTIONAL.  The URL of the endpoint offering introspection.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. A list of token formats supported by this AS.  The values in this list MUST be registered in the GNAP Token Format Registry. The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. REQUIRED.  The location of the AS's grant request endpoint, used by the RS to derive downstream access tokens.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST be the same URL used by client instances in support of GNAP requests. OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the "proof" field of the key section of the request. </del> 3.2. Unless otherwise specified, the RS MUST protect its calls to the AS The RS signs the request with its own key and sends the access token as the body of the request. <del> REQUIRED.  The access token value presented to the RS by the client instance. RECOMMENDED.  The proofing method used by the client instance to bind the token to the RS request. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The minimum access rights required to fulfill the request.  This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol. </del> The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that presentation, such as its intended proofing mechanism and key material. <del> REQUIRED.  If "true", the access token presented is active, as defined above.  If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to "false" and other fields are omitted. </del> If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following: <del> REQUIRED.  The access rights associated with this access token. This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol.  This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array. REQUIRED if the token is bound.  The key bound to the access token, to allow the RS to validate the signature of the request from the client instance.  If the access token is a bearer token, this MUST NOT be included. OPTIONAL.  The set of flags associated with the access token. </del> The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself. the AS's resource registration endpoint along with information about what the RS will need to validate the request. <del> REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </del> The RS MUST identify itself with its own key and sign the request. The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. <del> REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </del> 4. Some architectures require an RS to act as a client instance and use 5.  [[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <del> 5.1. </del>  This specification establishes the GNAP Token Format Registry to define token formats. <del> 5.1.1. </del>  <del> 5.1.2. </del>  The table below contains the initial contents of the GNAP Token Format Registry. <del> 6. </del>  [[ 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> 7. </del>  [[ 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> 8.  References </del>  <del> 8.1.  URIs </del>  [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115

Reviewer comments:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:

Revised text:
The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields:  3.2. Unless otherwise specified, the RS MUST protect its calls to the AS The RS signs the request with its own key and sends the access token as the body of the request.  The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that presentation, such as its intended proofing mechanism and key material.  If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following:  The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself. the AS's resource registration endpoint along with information about what the RS will need to validate the request.  The RS MUST identify itself with its own key and sign the request. The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests.  4. Some architectures require an RS to act as a client instance and use 5. <ins> (TODO: the ACK section should probably be split between the documents) 6. </ins> [[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]]  <ins> 6.1. </ins> This specification establishes the GNAP Token Format Registry to define token formats.  <ins> 6.1.1. </ins>  <ins> 6.1.2. </ins> The table below contains the initial contents of the GNAP Token Format Registry.  <ins> 7. </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.  <ins> 8. </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.  <ins> 9.  References </ins>  <ins> 9.1.  URIs </ins> [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115