Original text:
components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in {{I-D.ietf-gnap- resource-servers}}. To facilitate this extended use, the sections <del> below are defined in generic terms of the "sender" and "verifier" of the HTTP message.  In the core functions of GNAP, the "sender" is the </del>  client instance and the "verifier" is the AS or RS, as appropriate. When used for delegation in GNAP, these key binding mechanisms allow 7.3.1. This method is indicated by "httpsig" in the "proof" field.  The <del> sender creates an HTTP Message Signature as described in I-D.ietf- </del>  httpbis-message-signatures. The covered content of the signature MUST include the following: GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload. <del> The client instance presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </del>  In this example, the JOSE Header contains the following parameters: RFC7515 object is created as follows: The JOSE header MUST contain the "kid" parameter of the key bound to <del> this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </del>  To protect the request, the JWS header MUST contain the following additional parameters. If the HTTP request has a message body, such as an HTTP POST or PUT method, the payload of the JWS object is the JSON serialized body of the request, and the object is signed according to JWS and serialized <del> into compact form RFC7515.  The client instance presents the JWS as the body of the request along with a content type of "application/ jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. </del>  If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use

Revised text:
components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in {{I-D.ietf-gnap- resource-servers}}. To facilitate this extended use, the sections  <ins> below are defined in generic terms of the "signer" and "verifier" of the HTTP message.  In the core functions of GNAP, the "signer" is the </ins> client instance and the "verifier" is the AS or RS, as appropriate. When used for delegation in GNAP, these key binding mechanisms allow 7.3.1. This method is indicated by "httpsig" in the "proof" field.  The  <ins> signer creates an HTTP Message Signature as described in I-D.ietf- </ins> httpbis-message-signatures. The covered content of the signature MUST include the following: GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload.  <ins> The signer presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </ins> In this example, the JOSE Header contains the following parameters: RFC7515 object is created as follows: The JOSE header MUST contain the "kid" parameter of the key bound to  <ins> this signer for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by "kid" and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following additional parameters. If the HTTP request has a message body, such as an HTTP POST or PUT method, the payload of the JWS object is the JSON serialized body of the request, and the object is signed according to JWS and serialized  <ins> into compact form RFC7515.  The signer presents the JWS as the body of the request along with a content type of "application/jose".  The verifier MUST extract the payload of the JWS and treat it as the request body for further processing. </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated