jiebi/TextFlow huggingface dataset:
Original text:
To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier <del> for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. </del>  The identifier that the account is authorized to represent:

Reviewer comments:
Previously there was some notion of being able to hint to the server whether you wanted to reuse authorizations. This was removed from the spec but the pre-authorization flow still made a reference to it. This commit removes that obsolete reference. Thanks to NAME for pointing out the error. Resolves URL
Hi in the section on pre-authz there is this sentence: To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. the part "and how the server should behave with respect to existing authorizations for this identifier" probably is obsoleted
Hi NAME I submitted URL to fix this. Thanks for spotting & reporting :-)

Revised text:
To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier  <ins> for which authorization is being requested. </ins> The identifier that the account is authorized to represent:
Original text:
8.1. <del> Several of the challenges in this document make use of a key </del>  authorization string.  A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in <del> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in JWA RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </del>  As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-

Reviewer comments:
I think without OOB all challenges use key-authorization "JWA" is not defined in this document. I think it can just be omitted
NAME Thank you for the change! :smile:
Thanks again NAME I really appreciate your editing & the accompanying PRs! :-)

Revised text:
8.1.  <ins> All challenges defined in this document make use of a key </ins> authorization string.  A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in  <ins> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </ins> As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-
Original text:
Any identifier of type "dns" in a new-order request MAY have a wildcard domain name as its value.  A wildcard domain name consists of a single asterisk character followed by a single full stop <del> character ("_.") followed by a domain name as defined for use in the Subject Alternate Name Extension by RFC 5280 . An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("_RFC5280.") prefix in the authorization identifier value. </del>  The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents either

Reviewer comments:
Prior to this commit the literal string "." was being rendered as the start of italics in the generated HTML doc. This commit updates the markup to escape the "*."` in the generated document. Originally reported by Joel Sing - thanks!

Revised text:
Any identifier of type "dns" in a new-order request MAY have a wildcard domain name as its value.  A wildcard domain name consists of a single asterisk character followed by a single full stop  <ins> character ("*.") followed by a domain name as defined for use in the Subject Alternate Name Extension by RFC 5280 RFC5280.  An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix in the authorization identifier value. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents either
Original text:
a host which only functions as an ACME server could place the directory under the path "/".  The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.

Reviewer comments:
In Section 7.4.1 "Pre-Authorization" the spec says: If a CA wishes to allow pre-authorization within ACME, it can offer a "new authorization" resource in its directory by adding the field "newAuthz" with a URL for the new authorization resource. That text indicates that the CA may wish to not support pre-authorization in which case the "newAuthz" resource will not be present in the directory. One example of an ACME CA choosing to not support pre-authorization is Let's Encrypt. This commit clarifies the "newAuthz" field of the directory is optional in Section 7.1.1 "Directory" where a developer is likely to look to understand which resources must be supported/present in the directory and which are optional ("meta", "newAuthz"). If the server doesn't support pre-authorization it MUST omit the "newAuthz" field.

Revised text:
a host which only functions as an ACME server could place the directory under the path "/". <ins> If the ACME server does not implement pre-authorization (Section 7.4.1) it MUST omit the "newAuthz" field of the directory. </ins> The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.
Original text:
problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the <del> "urn:acme:" namespace): </del>  Authorization and challenge objects can also contain error information to indicate why the server was unable to validate

Reviewer comments:
In addition to adding the error, as proposed in , this PR fixes some issues discussed in the F2F meeting, namely moving ACME URNs under the IETF parameters space, and having errors be a sub-namespace of an overall ACME namespace.

Revised text:
problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the  <ins> "urn:ietf:params:acme:error:" namespace): This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers MUST NOT use the ACME URN namespace for errors other than the standard types.  Clients SHOULD display the "detail" field of such errors. </ins> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate
Original text:
The inner JWS MUST have the same "url" header parameter as the outer JWS. <del> The inner JWS MAY omit the "nonce" header parameter.  The server MUST ignore any value provided for the "nonce" header parameter. </del>  This transaction has signatures from both the old and new keys so that the server can verify that the holders of the two keys both

Reviewer comments:
URL
Thanks NAME On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote: My apologies if I missed it when it went by, but did we ever hear more about this requirement from the proponents of externalAccountBinding? Thanks, Benjamin

Revised text:
The inner JWS MUST have the same "url" header parameter as the outer JWS.  <ins> The inner JWS MUST omit the "nonce" header parameter. </ins> This transaction has signatures from both the old and new keys so that the server can verify that the holders of the two keys both
Original text:
Cut and paste the CSR into a CA's web page. <del> Prove ownership of the domain by one of the following methods: </del>  Put a CA-provided challenge at a specific place on the web server.

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
Cut and paste the CSR into a CA's web page.  <ins> Prove ownership of the domain(s) in the CSR by one of the following methods: </ins> Put a CA-provided challenge at a specific place on the web server.
Original text:
The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s).  For example, the <del> CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under </del>  http://example.com. Once the CA is satisfied, it issues the certificate and the ACME

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s).  For example, the  <ins> CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under </ins> http://example.com. Once the CA is satisfied, it issues the certificate and the ACME
Original text:
MUST verify the JWS before processing the request.  Encapsulating request bodies in JWS provides authentication of requests. <del> JWS objects sent in ACME requests MUST meet the following additional criteria: </del>  The JWS MUST be in the Flattened JSON Serialization

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
MUST verify the JWS before processing the request.  Encapsulating request bodies in JWS provides authentication of requests.  <ins> A JWS object sent as the body of an ACME request MUST meet the following additional criteria: </ins> The JWS MUST be in the Flattened JSON Serialization
Original text:
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 client requests.  The server MUST generate the value provided in Replay- Nonce in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </del>  <del> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </del>  RFC7515.  Clients MUST ignore invalid Replay-Nonce values.  The ABNF RFC5234 for the Replay-Nonce header field follows:

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
6.5.1.  <ins> The Replay-Nonce HTTP header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the values provided in Replay-Nonce header fields in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </ins>  <ins> The value of the Replay-Nonce header field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </ins> RFC7515.  Clients MUST ignore invalid Replay-Nonce values.  The ABNF RFC5234 for the Replay-Nonce header field follows:
Original text:
signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request. <del> The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal requirements, with the following differences: </del>  The inner JWS MUST have a "jwk" header parameter, containing the public key of the new key pair.

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request.  <ins> The outer JWS MUST meet the normal requirements for an ACME JWS request body (see request-authentication).  The inner JWS MUST meet the normal requirements, with the following differences: </ins> The inner JWS MUST have a "jwk" header parameter, containing the public key of the new key pair.
Original text:
old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </del>  Validate the POST request belongs to a currently active account, as described in message-transport.

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
old key.  The "outer" JWS represents the current account holder's assent to this request.  <ins> On receiving a keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport.
Original text:
That the client controls the identifier in question. <del> This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </del>  multiple entities to manage certificates). Authorization resources are created by the server in response to <del> certificate orders or authorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </del>  these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server in reply to a new order request, it downloads the authorization resources by sending </del>  POST-as-GET requests to the indicated URLs.  If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
That the client controls the identifier in question.  <ins> This process may be repeated to associate multiple identifiers with an account (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </ins> multiple entities to manage certificates). Authorization resources are created by the server in response to  <ins> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </ins> these requests.  The authorization object is implicitly tied to the account key used to sign the request.  <ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending </ins> POST-as-GET requests to the indicated URLs.  If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to
Original text:
representation of the challenge with the response object provided by the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. <del> The server provides a 200 (OK) response with the updated challenge object as its body. </del>  If the client's response is invalid for any reason or does not provide the server with appropriate information to validate the

Reviewer comments:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Revised text:
representation of the challenge with the response object provided by the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge.  <ins> Note that the challenges in this document do not define any response fields, but future specifications might define them.  The server provides a 200 (OK) response with the updated challenge object as its body. </ins> If the client's response is invalid for any reason or does not provide the server with appropriate information to validate the