Original text:
the request. The process by which the delegation happens is known as a grant, and <del> the GNAP protocol allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. </del>  This protocol solves many of the same use cases as OAuth 2.0 RFC6749, OpenID Connect OIDC, and the family of protocols that have grown up 1.2. <del> The parties in the GNAP protocol perform actions under different roles.  Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol. </del>  Manages the requested delegations for the RO.  The AS issues tokens and directly delegated information to the RC.  The AS is Operates and interacts with the RC. <del> The GNAP protocol design does not assume any one deployment architecture, but instead attempts to define roles that can be fulfilled in a number of different ways for different use cases.  As long as a given role fulfills all of its obligations and behaviors as defined by the protocol, GNAP does not make additional requirements on its structure or setup. </del>  Multiple roles can be fulfilled by the same party, and a given party can switch roles in different instances of the protocol.  For 1.4. <del> The GNAP protocol can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are </del>  conditionally present depending on the context of the deployments, and not every step in this overview will happen in all circumstances. access of the RS and no longer needs the token. The following sections and examples contain specific guidance on how <del> to use the GNAP protocol in different situations and deployments. </del>  1.4.1. ensure that nothing has been tampered with or substituted in a way that would change the nature of the request. <del> When used in the GNAP delegation protocol, these key binding mechanisms allow the AS to ensure that the keys presented by the RC in the initial request are in control of the party calling any follow-up or continuation requests.  To facilitate this requirement, all keys in the initial request request-key MUST be proved in all continuation requests continue-request and token management requests token-management, modulo any rotations on those keys over time that the AS knows about.  The AS MUST validate all keys request-key or referenced in an ongoing request for each call within that request. </del>  [[ See issue #105 [78] ]]

Reviewer comments:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.

Revised text:
the request. The process by which the delegation happens is known as a grant, and  <ins> GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. </ins> This protocol solves many of the same use cases as OAuth 2.0 RFC6749, OpenID Connect OIDC, and the family of protocols that have grown up 1.2.  <ins> The parties in GNAP perform actions under different roles.  Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol. </ins> Manages the requested delegations for the RO.  The AS issues tokens and directly delegated information to the RC.  The AS is Operates and interacts with the RC.  <ins> The design of GNAP does not assume any one deployment architecture, but instead attempts to define roles that can be fulfilled in a number of different ways for different use cases.  As long as a given role fulfills all of its obligations and behaviors as defined by the protocol, GNAP does not make additional requirements on its structure or setup. </ins> Multiple roles can be fulfilled by the same party, and a given party can switch roles in different instances of the protocol.  For 1.4.  <ins> GNAP can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are </ins> conditionally present depending on the context of the deployments, and not every step in this overview will happen in all circumstances. access of the RS and no longer needs the token. The following sections and examples contain specific guidance on how  <ins> to use GNAP in different situations and deployments. </ins> 1.4.1. ensure that nothing has been tampered with or substituted in a way that would change the nature of the request.  <ins> When used for delegation in GNAP, these key binding mechanisms allow the AS to ensure that the keys presented by the RC in the initial request are in control of the party calling any follow-up or continuation requests.  To facilitate this requirement, all keys in the initial request request-key MUST be proved in all continuation requests continue-request and token management requests token- management, modulo any rotations on those keys over time that the AS knows about.  The AS MUST validate all keys request-key or referenced in an ongoing request for each call within that request. </ins> [[ See issue #105 [78] ]]