Draft: draft-ietf-acme-acme

Commentary: As discussed at IETF 97 , this PR removes the " requirements " abstraction , and changes the " requirements " field in an application / order object to be an " authorizations " field . This is a replacement for . 
 Let 's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits , so they need a way for clients to clear these out . These clients are also not keeping around authorization URLs , so they ca n't just go them . My proposed solution would be to re - add the " authorizations " field to the account object , which got lost in the refactor in or so . Together with deactivation , enabling clients to enumerate authorization URLs would solve this problem . You could also envision a more direct solution , offering an endpoint that just deletes all pending authorizations for a client or client+identifier . 
 This is definitely too specific to these buggy clients . For the flow , the list of orders is sufficient . It 's true that technically you can create authorizations through a separate , optional , flow . But Let 's  has no plans to implement that flow , because other CAs have said they can not / would not implement it , so Let 's Encrypt implementing it would split the market . I 'm inclined to say let 's not complicate the protocol , and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs . Also , I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol . 
 If is merged , I would expect that a reasonable ACME server supporting new - authz would return an exiting authz , instead of giving a rate limit error . Or return existing authz from the beginning . 
 Closing as a result of WG decision at IETF 98
Paragraph (version B):
For pending orders, the authorizations that the client needs to
complete before the requested certificate can be issued (see
identifier-authorization).  For final orders, the authorizations
that were completed.  Each entry is a URL from which an
authorization can be fetched with a GET request.
Paragraph (version A):
The elements of the "authorizations" array are immutable once set,
except for their "status" fields.  If any other part of the object
changes after the object is created, the client MUST consider the
order invalid.
Paragraph (version B):
The elements of the "authorizations" array are immutable once set.
If any change is made to the array after the object is created, the
client MUST consider the order invalid.
Paragraph (version A):
The order object returned by the server represents a promise that if
the client fulfills the server's requirements before the "expires"
time, then the server will issue the requested certificate.  In the
order object, any object in the "authorizations" array whose status
is "pending" represents an authorization transaction that the client
must complete before the server will issue the certificate (see
identifier-authorization).  If the client fails to complete the
required actions before the "expires" time, then the server SHOULD
change the status of the order to "invalid" and MAY delete the order
resource.
Paragraph (version B):
The order object returned by the server represents a promise that if
the client fulfills the server's requirements before the "expires"
time, then the server will issue the requested certificate.  In the
order object, any authorization referenced in the "authorizations"
array whose status is "pending" represents an authorization
transaction that the client must complete before the server will
issue the certificate (see identifier-authorization).  If the client
fails to complete the required actions before the "expires" time,
then the server SHOULD change the status of the order to "invalid"
and MAY delete the application resource.
Paragraph (version A):
The server MUST issue the requested certificate and update the order
resource with a URL for the certificate as soon as the client has
fulfilled the server's requirements.  If the client has already
satisfied the server's requirements at the time of this request
(e.g., by obtaining authorization for all of the identifiers in the
certificate in previous transactions), then the server MUST
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the order.  The server MUST, however,
still list the completed authorizations in the "authorizations"
array, with the state "valid".
Paragraph (version B):
The server MUST issue the requested certificate and update the order
resource with a URL for the certificate as soon as the client has
fulfilled the server's requirements.  If the client has already
satisfied the server's requirements at the time of this request
(e.g., by obtaining authorization for all of the identifiers in the
certificate in previous transactions), then the server MUST
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the order.  The server MUST, however,
still list the completed authorizations in the "authorizations"
array.
Paragraph (version A):
When a client receives an order from the server with "pending" entry
in the authorizations array, it downloads the authorization resource
by sending a GET request to the indicated URL.  If the client
initiates authorization using a request to the new authorization
resource, it will have already recevied the pending authorization
object in the response to that request.
Paragraph (version B):
When a client receives an order from the server it downloads the
authorization resource by sending a GET request to the indicated URL.
If the client initiates authorization using a request to the new
authorization resource, it will have already recevied the pending
authorization object in the response to that request.