Original text:
"alg" (Algorithm) <del> "jwk" (JSON Web Key, only for requests to new-account and revoke-cert resources) </del>  <del> "kid" (Key ID, for all other requests) </del>  "nonce" (defined in replay-protection below) The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. <del> For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </del>  <del> For all other requests, there MUST be a "kid" field.  This field must contain the account URL received by POSTing to the new-account resource. </del>  Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET 7.6. To request that a certificate be revoked, the client sends a POST <del> request to the ACME server's revoke-cert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </del>  revoked: The certificate to be revoked, in the base64url-encoded version of Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in <del> the certificate.  Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate.  The server MUST consider at least the following accounts authorized for a given certificate: </del>  the account that issued the certificate.

Reviewer comments:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.

Revised text:
"alg" (Algorithm)  <ins> "jwk" (JSON Web Key, for all requests not signed using an existing account, e.g. newAccount) </ins>  <ins> "kid" (Key ID, for all requests signed using an existing account) </ins> "nonce" (defined in replay-protection below) The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both.  <ins> For newAccount requests, and for revokeCert requests authenticated by certificate key, there MUST be a "jwk" field.  This field MUST contain the public key corresponding to the private key used to sign the JWS. </ins>  <ins> For all other requests, the request is signed using an existing account and there MUST be a "kid" field.  This field MUST contain the account URL received by POSTing to the newAccount resource. </ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET 7.6. To request that a certificate be revoked, the client sends a POST  <ins> request to the ACME server's revokeCert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </ins> revoked: The certificate to be revoked, in the base64url-encoded version of Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in  <ins> the certificate. Example using an account key pair for the signature: Example using the certificate key pair for the signature: Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server MUST consider at least the following accounts authorized for a given certificate: </ins> the account that issued the certificate.