Hi,
I have missed the following sentence:
A request to finalize an order will result in error if …
the account is not authorized for the identifiers
This was also the intention behind introducing finalization in the first
place. Therefore, this is clarified for me.
However, I want to suggest that the following issues in the draft still
need clarification:
1.
Once the client believes it has fulfilled the server's requirements,
it should send a POST request to the order resource's finalize URL.
This should not be based on a "believe". The client fulfills the
challenge and responds to the challenge afterwards. Then the client
should begin polling <to be decided> until all authorizations are valid.
Only then it should try to finalize.
2.
A request to finalize an order will result in error if the order
indicated does not have status "pending" … or if the account is not
authorized for the identifiers
…
"pending": The server does not believe that the client has fulfilled
the requirements. Check the "authorizations" array for entries that
are still pending.
This is contradictory. It says: To finalize you need the state that
corresponds to 'unauthorized' but you must be 'authorized' at the same time.
One question is: Should the order object reflect the state of the
authorizations? I don't see arguments against it. Clients polling all
authorizations is more expensive then the server having to lookup the
first authorization that is not 'valid'.
I am suggesting the following order states
pending: Authorizations need user action
validating: Please poll order/authz until server has validated
authorized: Please finalize ('finalize' key only present in this state)
issuing: Called 'processing' before
issued: Certificate ready ('certificate' key only present in this state)
invalid: Authorization failed, error or expired
3.
The status of this authorization. Possible values are: "pending",
"processing", "valid", "invalid" and "revoked".
…
sending POST requests with the static object {"status":
"deactivated"} to each authorization URL
The meanings of the statuses "pending", "processing" are not defined. It
also seems like there should be an "deactivated" status as well?
"processing" could probably be call "validating".
4.
The status of this challenge. Possible values are: "pending",
"valid", and "invalid".
Again no definition of the meaning. I think the server should reflect if
the challenge has been 'responded' by the client. This would need an
extra field like "processing" or "validating".
5.
For challenges where the client can tell when the server has
validated the challenge (e.g., by seeing an HTTP or DNS request from
the server), the client SHOULD NOT begin polling until it has seen
the validation request from the server.
I suggest removing this paragraph. There is no reason why only one
request for validation should happen from the server. Doesn't LE already
have distributed validation servers? Anyways, I would suggest to focus
on the Retry-After header instead. This is something client libraries
can give a general solution for. The Retry-After header could already be
send as an answer to the the challenge response POST. Or is there a
problem with servers not having a good Retry-After estimate?
6.
At least the "typical sequence of requests" table is lacking a polling
step before the "Finalize order" step.
Best,
Sophie
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
