Original text:
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 <del> 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 of For final authorizations, it contains the challenges that were successfully completed.  The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the <del> first label) MUST NOT be included in authorization objects. </del>  identifier-validation-challenges describes a set of challenges for domain name validation.

Reviewer comments:
requests are allowed to send DNS type identifiers with a value that contains a wildcard prefix ('') as the leftmost label. The authorization object created for the wildcard identifiers in the requests are not allowed to carry the wildcard prefix in the authorization identifier per spec language: This is sensible because the authorization is not for the logical wildcard but for the specific base domain. This leaves an ambiguous situation for client developers/users. Imagine a situation where a user requests a new order with the following request body: It's possible two authorizations will be created for this case, but both will contain the identifier . This can be confusing to users! (e.g. shred/acme4j) If one of the authorizations fails a challenge validation operation the client can't know whether it was the "URL" validation, or the "URL" validation that failed and won't be able to prompt the user to retry with the failed domain removed. Generally speaking it makes presenting accurate error information difficult without over-fitting Let's Encrypt's particular Wildcard issuance policies. (E.g. see discussion in URL and URL) This commit introduces an optional boolean authorization field that can be used to indicate the authorization's identifier should be considered the base domain of a wildcard identifier that was requested. This replaces , which included the baggage of .

Revised text:
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  <ins> in the authorization identifier value.  The returned authorization MUST include the optional "wildcard" field, with a value of true. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents of For final authorizations, it contains the challenges that were successfully completed. <ins> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard prefix this field MUST be present, and true. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the  <ins> first label) MUST NOT be included in authorization objects.  If an authorization object 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. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.