> On Jul 16, 2019, at 9:28 AM, Daniel McCarney <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
