Original text:
The JWS MUST NOT have the value "none" in its "alg" field  The JWS MUST NOT have a Message Authentication Code (MAC)-based algorithm in its "alg" field document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. <del> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. </del> 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 provided to clients and having the resource check that requests have the same string in their "url" header parameter. <del> 6.3.1. </del>  The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL. <del> 6.4. </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.4.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.4.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.5. </del>  Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the "Link" header pointing to documentation about the specific rate limit that was hit, using the "help" link relation type. <del> 6.6. </del>  Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR". <del> 6.6.1. </del>  Sometimes a CA may need to return multiple errors in response to a request.  Additionally, the CA may need to attribute errors to

Reviewer comments:
This change is designed to partially address the JWS serialization format issues raised in the and threads on the mailing list. This change uses the Content-Type header to specify JWS serialization formats, and includes restrictions on the serializations. It doesn't include converting between serializations, or how to handle inner JWS messages. In short, this change should be a cleaner version of that still allows the compact serialization. Specifically, this change requires ACME implementations to use the HTTP Content-Type header to indicate the JWS serialization format used for the request body. The change also specifies restrictions on the specific serialization formats when used with ACME (don't use unencoded payloads, don't use detached payloads, don't use unprotected headers). In addition, the change prohibits multiple signatures in JWS objects used for ACME purposes. This change doesn't include advice on how to convert between the JWS serializations. Converting between JWS serializations may be needed if, for example, an ACME implementation uses a JWS library that doesn't support all JWS serializations and/or doesn't provide programmers with control over what JWS serialization is produced. In such cases, programmers may have to convert between JWS serializations before and/or after using said pre-existing JWS library. I have started a draft of a separate JOSE serialization conversion guide at URL The separate conversion guide is designed to not be ACME-specific. Accordingly, the separate conversion guide includes things like unencoded payloads, detached payloads, unprotected headers, and JWEs. One thing that is not included in this change is how the serialization format requirements should be applied to a "nested" JWS like the one found in a key change or an external account binding. Should a "nested" JWS be required to use the same serialization as the "outer" JWS? If a nested JWS should follow the outer JWS serialization format, the following additional changes may need to be made: Change the new "JWS Serialization Formats" section (introduced in this pull request). For example, the list in that section could be changed to the following: Content-Type "application/jose": A JWS of this Content-Type MUST meet the following criteria: The JWS Compact Serialization {{!RFC7515}} MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option {{!RFC7797}} MUST NOT be used. A JWS placed anywhere inside the payload of a JWS of this Content-Type MUST meet the above criteria as well. Content-Type "application/jose+json": A JWS of this Content-Type MUST meet the following criteria: Either the JWS Flattened JSON {{!RFC7515}} or the JWS General JSON {{!RFC7515}} Serialization MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option {{!RFC7797}} MUST NOT be used. The JWS Unprotected Header {{!RFC7515}} SHOULD NOT be used. A JWS placed anywhere inside the payload of a JWS of this Content-Type MUST meet the above criteria as well. Update the specifications for the nested JWS: Right now, "externalAccountBinding" can be an object. If this JWS must follow the same guidelines as the outer JWS, "externalAccountBinding" could be an "object or string", depending on whether a JSON or compact serialization is used. If I understand correctly, the payload of the outer JWS for the "keyChange" (Account Key Roll-Over) endpoint is not a JSON object like in the other ACME requests. Instead, the payload for the "outer" JWS for this endpoint is merely this nested JWS itself. If this understanding is correct, I don't think any changes have to be made. If this understanding is not correct, I am not sure what changes may have to be made.
I verified locally that this branch passes CI tests. For some reason, I don't have permission to re-run CI. I'm about to send another PR on top of this one to fix a minor bug, so CI will run then.

Revised text:
The JWS MUST NOT have the value "none" in its "alg" field <ins> The JWS MUST NOT have multiple signatures. </ins> The JWS MUST NOT have a Message Authentication Code (MAC)-based algorithm in its "alg" field document returned with the error MUST include an "algorithms" field with an array of supported "alg" values.  6.3. <ins> The JSON Web Signature (JWS) specification RFC7515 contains multiple JWS serialization formats.  When sending an ACME request with a non- empty body, an ACME client implementation MUST use the HTTP Content- Type RFC7231 header to indicate which JWS serialization format is used for encapsulating the ACME request payload.  The following Content-Type values may be used for this purpose: "application/jose": The JWS Compact Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option RFC7797 MUST NOT be used. "application/jose+json": Either the JWS Flattened JSON Serialization RFC7515 or the JWS General JSON Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option RFC7797 MUST NOT be used. The JWS Unprotected Header RFC7515 SHOULD NOT be used. In the examples below, JWS objects are shown in the General JSON or Flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. 6.4. </ins> 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 provided to clients and having the resource check that requests have the same string in their "url" header parameter.  <ins> 6.4.1. </ins> The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL.  <ins> 6.5. </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.5.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.5.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.6. </ins> Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the "Link" header pointing to documentation about the specific rate limit that was hit, using the "help" link relation type.  <ins> 6.7. </ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. example, an "error of type 'badCSR'" refers to an error document with "type" value "urn:ietf:params:acme:error:badCSR".  <ins> 6.7.1. </ins> Sometimes a CA may need to return multiple errors in response to a request.  Additionally, the CA may need to attribute errors to