Original text:
the server for information about its account (e.g., to examine the "contact" or "certificates" fields), then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS <del> whose payload is trivial ({"resource":"reg"}). </del>  6.3.1. The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in <del> the elements of the "challenges" dictionary.  For example, if the client wishes to complete the "simpleHttp" challenge, it needs to provide the "path" component.  (This is also the stage where the client should perform any actions required by the challenge.) </del>  The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, an entity applying for a certificate with a given identifier actually controls that identifier. <del> Challenges provide the server with assurance the an account key </del>  holder is also the entity that controls an identifier.  For each type of challenge, it must be the case that in order for an entity to successfully complete the challenge the entity must both: its control over a domain name by proving that it can provision resources on an HTTP server that responds for that domain name.  The ACME server challenges the client to provision a file with a specific <del> string as its contents. </del>  As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA The string "simpleHttp" <del> The value to be provisioned in the file.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any non-ASCII characters. </del>  A client responds to this challenge by signing a JWS object and provisioning it as a resource on the HTTP server for the domain in question.  The payload of the JWS MUST be a JSON dictionary <del> containing the fields "type", "token", "path", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </del>  "tls" field is not included in the response, then validation object MUST have its "tls" field set to "true".  The JWS MUST be signed with the client's account key pair.  This JWS is NOT REQUIRED to have a HTTPS server. Verify that the Content-Type header of the response is either <del> absent, or has the value "application/jose+json" </del>  <del> Verify that the body of the response is a valid JWS of the type indicated by the Content-Type header (if present), signed with the client's account key </del>  Verify that the payload of the JWS meets the following criteria: * <del> It is a valid JSON dictionary * It has exactly four fields * Its "type" field is set to "simpleHttp" * Its "token" field is equal to the "token" field in the challenge * Its "path" field is equal to the "path" field in the response * Its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent </del>  <del> Comparisons of the "path" and "token" fields MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </del>  If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del>  In response to the challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del>  The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as The string "dns" <del> A random value with at least 128 bits of entropy.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </del>  In response to this challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dns" <del> The token value in the challenge </del>  The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as

Reviewer comments:
(As part of closing out the letsencrypt/acme-spec repo.)

Revised text:
the server for information about its account (e.g., to examine the "contact" or "certificates" fields), then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS  <ins> whose payload is trivial ({"resource":"reg"}).  In this case the server reply MUST contain the same link headers sent for a new registration, to allow a client to retreive the "new-authorization" and "terms-of-service" URI </ins> 6.3.1. The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in  <ins> the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, an entity applying for a certificate with a given identifier actually controls that identifier.  <ins> Challenges provide the server with assurance that an account key </ins> holder is also the entity that controls an identifier.  For each type of challenge, it must be the case that in order for an entity to successfully complete the challenge the entity must both: its control over a domain name by proving that it can provision resources on an HTTP server that responds for that domain name.  The ACME server challenges the client to provision a file with a specific  <ins> JWS as its contents. </ins> As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA The string "simpleHttp"  <ins> The value to be used in generation of validation JWS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> A client responds to this challenge by signing a JWS object and provisioning it as a resource on the HTTP server for the domain in question.  The payload of the JWS MUST be a JSON dictionary  <ins> containing the fields "type", "token", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </ins> "tls" field is not included in the response, then validation object MUST have its "tls" field set to "true".  The JWS MUST be signed with the client's account key pair.  This JWS is NOT REQUIRED to have a HTTPS server. Verify that the Content-Type header of the response is either  <ins> absent, or has the value "application/jose+json". </ins>  <ins> Verify that the body of the response is a valid JWS, signed with the client's account key. </ins> Verify that the payload of the JWS meets the following criteria: *  <ins> it is a valid JSON dictionary; * it has exactly three fields; * its "type" field is set to "simpleHttp"; * its "token" field is equal to the "token" field in the challenge; * its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent. </ins>  <ins> Comparisons of the "token" field MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these The string "dvsni"  <ins> The value to be used in generation of validation certificate. This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to the challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dvsni"  <ins> The token value from the server-provided challenge object </ins> The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as The string "dns"  <ins> The value to be used in generation of validation record to be provisioned in DNS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to this challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dns"  <ins> The token value from the server-provided challenge object </ins> The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as