Original text:
6.3. <del> At some points in the protocol, it is necessary for the server to determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in all fields included in the computation of a JWK thumbprint for that key.  That is, the keys must have the same "kty" value and contain identical values in the fields used in the computation of a JWK thumbprint for that key type: "RSA": "n", "e" "EC": "crv", "x", "y" Note that this comparison is equivalent to computing the JWK thumbprints of the two keys and comparing thumbprints.  The only difference is that there is no requirement for a hash computation (and thus it is independent of the choice of hash function) and no risk of hash collision. 6.4. </del> It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, with a "request routing" layer in the middle.  For example, an ACME having the resource check that requests have the same string in their "url" fields. <del> 6.4.1. </del>  The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a string representing the URL. <del> 6.5. </del>  In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 6.5.1. </del>  The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 6.5.2. </del>  The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 6.6. </del>  Creation of resources can be rate limited to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the server MUST header pointing to documentation about the specific hit rate limits using the "urn:ietf:params:acme:documentation" relation. <del> 6.7. </del>  Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. the same. Check that the "account" field of the key-change object contains <del> the URL for the account matching the old key. </del>  <del> Check that the "newKey" field of the key-change object contains the key used to sign the inner JWS. </del>  If all of these checks pass, then the server updates the corresponding account by replacing the old account key with the new

Reviewer comments:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.

Revised text:
6.3.  It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, with a "request routing" layer in the middle.  For example, an ACME having the resource check that requests have the same string in their "url" fields.  <ins> 6.3.1. </ins> The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a string representing the URL.  <ins> 6.4. </ins> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism value for each response, keep a list of issued nonces, and strike nonces from this list as they are used.  <ins> 6.4.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages.  <ins> 6.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed.  <ins> 6.5. </ins> Creation of resources can be rate limited to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the server MUST header pointing to documentation about the specific hit rate limits using the "urn:ietf:params:acme:documentation" relation.  <ins> 6.6. </ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. the same. Check that the "account" field of the key-change object contains  <ins> the URL for the account matching the old key </ins>  <ins> Check that the "newKey" field of the key-change object also verifies the inner JWS. </ins> If all of these checks pass, then the server updates the corresponding account by replacing the old account key with the new