Original text:
This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a <del> value that contained a wildcard prefix.  For other authorizations, it MUST be absent. </del>  The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object <del> conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix, then the optional authorizations "wildcard" field MUST be present with a value of true. </del>  identifier-validation-challenges describes a set of challenges for domain name validation. A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a <del> 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </del>  If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- <del> authorization cannot be used to authorize issuance with wildcard DNS identifiers. </del>  Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the

Reviewer comments:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:

Revised text:
This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a  <ins> value that was a wildcard domain name.  For other authorizations, it MUST be absent.  Wildcard domain names are described in order- objects. </ins> The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object  <ins> conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation. A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a  <ins> 403 (Forbidden) error with a problem document of type "orderNotReady".  The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </ins> If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre-  <ins> authorization cannot be used to authorize issuance of certificates containing wildcard domain names. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the