Richard: That's up to the client and the situation. In the linked Certbot
issues there were questions about error output/UX. In this case if the
client saw an error attached to an authorization with the identifier `{
"type": "dns", "value": ""}` and the authorization had
`wildcard: true` the client could say "Failed to authorize *
blah blah blah" or otherwise use the knowledge to inform their actions
(whatever they may be).

In general I think there will be reason for client developers will want to
have a standardized way of understanding if an authorization corresponds to
a wildcard identifier or not. I'm hopeful some client developers will chime
in with more concrete examples, I'm a server-side grunt.

- Daniel / cpu

On Fri, Mar 2, 2018 at 12:29 PM, Richard Barnes <> wrote:

> Daniel: I don't have a strong objection here, but could you elaborate what
> the client is expected to do differently based on this flag?
> On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney <>
> wrote:
>> Hi folks,
>> There is a slight disconnect with the current specification between
>> identifiers in newOrder/newAuthz requests and identifiers in authorization
>> objects. The former is allowed to include wildcard domains in the value of
>> DNS type identifiers while the latter is forbidden.
>> Let's Encrypt's implementation of ACME wildcard issuance guessed this
>> might lead to confusion and introduced a non-standardized "Wildcard"
>> boolean field in authorization objects. If true, then the identifier value
>> in the authorization identifier is known to be the base domain
>> corresponding to a wildcard identifier from the newOrder/newAuthz request.
>> I think it would be beneficial to the entire ecosystem if this optional
>> "wildcard" authz field could be standardized so I've sent a small PR:
>> Both Certbot and ACME4J
>> have independently bumped into this disconnect, which helps justify the
>> need.
>> - Daniel / cpu
>> _______________________________________________
>> Acme mailing list
Acme mailing list

Reply via email to