I think the general concept is good, and if we go this route I agree
that it should replace new-authz. However, I think there are significant
details to be worked out, and Eric's feedback is good. I don't want to
rush this into the spec because we have a document deadline coming up.
I'd rather take the time to discuss it further and flesh it out better.
And my apologies for letting this sit so long.
Some more specific feedback:
I think problem documents aren't the right tool for the precondition
response, and 412 isn't the right status code. Requesting a certificate
and getting a list of preconditions is an expected, normal thing, not an
error. Let's split out the "ask for preconditions" step from the "I'm
done" step. Something like:
POST /acme/submit-csr
201 Created
Location: /acme/requests/123
GET /acme/requests/123
{
requirements: [
{ type: authz, url: ..., status: completed },
{ type: authz, url: ..., status: pending },
]
}
... fulfill the requirements ...
POST /acme/finalize-csr
This avoids the loop that Eric describes, and makes it easy to see what
still needs to be done. It also means that issuing a certificate for
which all authz's are already validated follows the same flow as issuing
one where they are not. You submit the CSR, get back a request object
with all members "completed", and go on to post to the finalize-csr
resource.
Your example structure has a precondition of type registration. I think
we shouldn't treat registration as a precondition that can be returned
from submit-csr. Instead, it should be as it stands today - you must
register before you can submit any authenticated ACME requests. So we
should remove that example precondition.
More generally, if we're going to support preconditions with type other
than authz, we should have a more specific design for how they're going
to work. For instance, in the payment case, how does the client find out
when payment has been completed?
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
