Original text:
waiting for the RO to authorize the request. The client instance request.  The client instance does not send <del> any interactions modes to the server, indicating that it does not </del>  expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using the request-user. 1.5.4. In this example flow, the AS policy allows the client instance to <del> make a call on its own behalf, without the need for a RO to be </del>  involved at runtime to approve the decision.  Since there is no explicit RO, the client instance does not interact with an RO. The client instance request.  The client instance does not send <del> any interactions modes to the server. </del>  The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to requesting that the client instance present specific additional information, such as a user's credential or an assertion <del> contacting a RO through an out-of-band mechanism, such as a push </del>  notification contacting an auxiliary software process through an out-of-band In GNAP, key-bound access tokens are the default due to their higher security properties.  While bearer tokens can be used in GNAP, their <del> use should be limited onto to cases where the simplicity benefits outweigh the significant security downsides. </del>  11.8. request with their own keys, thereby negating the benefits of using key-bound access tokens. <del> The RS also needs to ensure that a sufficient portions of the message </del>  are covered by the signature.  Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation.  As such, an interception and possible manipulation by elements within the browser such as scripts loaded within pages.  Information in the URL is exposed through browser and server logs, and can also leak to other <del> parties through HTTP "Referrer" headers. </del>  GNAP's design limits the information passed directly through the browser, allowing for opaque URLs in most circumstances.  For the 11.17. The mtls provides a means for a client instance to present a key <del> using a certificate the TLS layer.  Since TLS protects the entire </del>  HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two.  However, since TLS is functioning at a separate layer from be presented over the TLS channel in question with the same level of trust.  The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request.  For <del> example, if the request is a grant request [40], the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </del>  Furthermore, the prevalence of the TLS-terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation.  In protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for <del> user indefinitely, in order to be able to include them in the </del>  responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. [38] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 [39] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 <del> [40] request </del>

Reviewer comments:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:

Revised text:
waiting for the RO to authorize the request. The client instance request.  The client instance does not send  <ins> any interaction modes to the server, indicating that it does not </ins> expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using the request-user. 1.5.4. In this example flow, the AS policy allows the client instance to  <ins> make a call on its own behalf, without the need for an RO to be </ins> involved at runtime to approve the decision.  Since there is no explicit RO, the client instance does not interact with an RO. The client instance request.  The client instance does not send  <ins> any interaction modes to the server. </ins> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to requesting that the client instance present specific additional information, such as a user's credential or an assertion  <ins> contacting an RO through an out-of-band mechanism, such as a push </ins> notification contacting an auxiliary software process through an out-of-band In GNAP, key-bound access tokens are the default due to their higher security properties.  While bearer tokens can be used in GNAP, their  <ins> use should be limited to cases where the simplicity benefits outweigh the significant security downsides. </ins> 11.8. request with their own keys, thereby negating the benefits of using key-bound access tokens.  <ins> The RS also needs to ensure that sufficient portions of the message </ins> are covered by the signature.  Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation.  As such, an interception and possible manipulation by elements within the browser such as scripts loaded within pages.  Information in the URL is exposed through browser and server logs, and can also leak to other  <ins> parties through HTTP "Referer" headers. </ins> GNAP's design limits the information passed directly through the browser, allowing for opaque URLs in most circumstances.  For the 11.17. The mtls provides a means for a client instance to present a key  <ins> using a certificate at the TLS layer.  Since TLS protects the entire </ins> HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two.  However, since TLS is functioning at a separate layer from be presented over the TLS channel in question with the same level of trust.  The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request.  For  <ins> example, if the request is a request, the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </ins> Furthermore, the prevalence of the TLS-terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation.  In protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for  <ins> users indefinitely, in order to be able to include them in the </ins> responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. [38] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 [39] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109