Re: [Acme] Optional "Wildcard" authorization field

> > I would propose we stick with a simpler solution here. While Sophie's > solution does seem more general, in the interest of getting the spec > shipped, I would propose we just add the boolean flag and write an > extension spec if a more general solution is needed. That sounds sensible to

Re: [Acme] Optional "Wildcard" authorization field

This is seeming like a lot of work for a pretty minor use case. I would propose we stick with a simpler solution here. While Sophie's solution does seem more general, in the interest of getting the spec shipped, I would propose we just add the boolean flag and write an extension spec if a more

Re: [Acme] Optional "Wildcard" authorization field

> > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object? Generally speaking yes. In principle, several order identifiers could lead to a single > authorization I guess? > I think in principle that's true. ACME doesn't

Re: [Acme] Optional "Wildcard" authorization field

On 02/03/18 18:32, Daniel McCarney wrote: > 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":

Re: [Acme] Optional "Wildcard" authorization field

In a similar vein, another small but real world example where this being standardized would be useful is Certbot has the flag —allow-subset-of-names that causes it to not treat it as a failure if you cannot complete all authorizations and instead obtain a certificate only for the identifiers

Re: [Acme] Optional "Wildcard" authorization field

Hi! I also see the problem that clients might get confused because there are seemingly two authentications for the very same domain ("example.com"). Without a proper flag, they could only be distinguished by the different set of challenges, but that would assume knowledge of server internas.

Re: [Acme] Optional "Wildcard" authorization field

Hi! I also see the problem that clients might get confused because there are seemingly two authentications for the very same domain ("example.com"). Without a proper flag, they could only be distinguished by the different set of challenges, but that would assume knowledge of server internas.

Re: [Acme] Optional "Wildcard" authorization field

One (fairly) obvious use of the “wildcard” flag is for status reporting without the context of the original newOrder. The client can thus more easily say: Authorization for “*.example.com”: $message … without having to correlate the authz object with the order. -FG > On Mar 2, 2018, at 12:32

Re: [Acme] Optional "Wildcard" authorization field

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": "example.com"}` and the authorization had `wildcard:

Re: [Acme] Optional "Wildcard" authorization field

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