Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Built Explore the source changes : 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 and 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
Paragraph (version A):
The key binding methods in this section MAY be used by other
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
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
client instance and the "verifier" is the AS or RS, as appropriate.
Paragraph (version B):
The key binding methods in this section MAY be used by other
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
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
client instance and the "verifier" is the AS or RS, as appropriate.
Paragraph (version A):
This method is indicated by "httpsig" in the "proof" field.  The
sender creates an HTTP Message Signature as described in I-D.ietf-
httpbis-message-signatures.
Paragraph (version B):
This method is indicated by "httpsig" in the "proof" field.  The
signer creates an HTTP Message Signature as described in I-D.ietf-
httpbis-message-signatures.
Paragraph (version A):
The client instance presents the signed object in compact form
RFC7515 in the Detached-JWS HTTP Header field.
Paragraph (version B):
The signer presents the signed object in compact form RFC7515 in the
Detached-JWS HTTP Header field.
Paragraph (version A):
The JOSE header MUST contain the "kid" parameter of the key bound to
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".
Paragraph (version B):
The JOSE header MUST contain the "kid" parameter of the key bound to
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".
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.