Re: [Acme] orders, authorizations, and identifiers (oh my)

[Daniel McCarney <[e-mail]>]

>
> 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?


No, if the server returned three authorizations all three must be
status=valid for the order to be ready for issuance. Earlier drafts had a
notion of challenge combinations that would allow something sort of similar
but it was dropped.

Per 7.1.6:

Order objects are created in the "pending" state. Once all of the
> authorizations listed in the order object are in the "valid" state, the
> order transitions to the "ready" state.


The server policy is exercised by the choice of authorizations/challenges
in the pending order, not by the client deciding which authorizations in an
order to satisfy.

On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper <[e-mail]>
wrote:

>
> > On Jul 16, 2019, at 9:28 AM, Daniel McCarney <[e-mail]>
> 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