> On Jul 16, 2019, at 9:28 AM, Daniel McCarney <c...@letsencrypt.org> wrote: > > So it would be reasonable for this order to contain a single authz … and > would that authz’s identifier be just “example.com”, then? Thus that authz > object would not reference “www”, even though it is that domain’s > corresponding authz object? Or would a client be accountable for implementing > a “best-match authz” lookup to determine which authz corresponds to a given > domain? > > Yes, I would expect the order's one authorization to have the identifier > "example.com". > > I believe the confusion here is when you say "even though it is that domain's > corresponding authz object" and "Since the order requires successful authz > for both domains". > > For the first part, as I understand there is no guaranteed correspondence > between any of the identifiers in the order request and the identifiers in > the returned authorizations. That's what the sentence you quoted on p26 is > meant to convey. The client shouldn't attempt to match authz's to requested > identifiers at all, it should just look at the identifiers in the > authorizations returned by the server and prove control of those identifiers > with the challenges available.
Thank your for your response. I think I see what’s going on. To flesh out a hypothetical a bit more: order identifiers: example.com, www.example.com authzs: 0) - identifier: { type: person, value: Fred } - challenge: ask if it’s ok 1) - identifier: { type: person, value: Jane } - challenge: ask if it’s ok 2) - identifier: { type: person, value: Pat } - challenge: ask if it’s ok So if we tell the human operator, “Jane & Pat gave the OK, but Fred said not”, then it’s left to server policy to determine whether that means a hypothetical order with just one or the other domain would pass all authzs? -F _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme