Original text:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517.  An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. 6.3.2. <del> If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete" field. delete (required, boolean): The boolean value "true". The request object MUST contain the "resource" field as required above (with the value "reg").  It MUST NOT contain any fields besides "resource" and "delete". </del>  <del> Note that although this object is very simple, the risk of replay or fraudulent generation via signing oracles is mitigated by the need for an anti-replay token in the protected header of the JWS. </del>  <del> On receiving a POST to an account URI containing a "delete" field, the server MUST verify that no other fields were sent in the object (other than "resource"), and it MUST verify that the value of the "delete" field is "true" (as a boolean, not a string).  If either of these checks fails, then the server MUST reject the request with status code 400 (Bad Request). If the server accepts the deletion request, then it MUST delete the account and all related objects and send a response with a 200 (OK) status code and an empty body.  The server SHOULD delete any authorization objects related to the deleted account, since they can no longer be used.  The server SHOULD NOT delete certificate objects related to the account, since certificates issued under the account continue to be valid until they expire or are revoked. </del>  6.4. If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server <del> delete the authorization.  The client makes this request by sending a POST request to the authorization URI containing a payload in the same format as in deleting-an-account.  The only difference is that the value of the "resource" field is "authz". The server MUST perform the same validity checks as in deleting-an- account and reject the request if they fail.  If the server deletes the account then it MUST send a response with a 200 (OK) status code and an empty body. </del>  6.5.

Reviewer comments:
This simplifies both the spec and the implementation, and does not attempt to impose specific data retention policy on the CA.
I don't really agree about that one. Why not delete completely the data instead of deactivating? Why shouldn't a user be able to request full deletion and no retention of any of their account data?
Nothing in this change prevents CAs from choosing to delete account data immediately upon deactivation, but the spec should not try to dictate policy.
I think this PR is fine in principal, but I have some minor concerns: If we're going to use the field, we should prefer to use the values that are already there, namely and . Do you think there's a semantic difference between that and what you're proposing? Your edits remove the guidance on what the server should return from these requests. Please add that back in. It occurs to me looking at this that the first version of authz deletion should have specified that the server MUST verify that the account is the owner of the authz before allowing it to deactivate the authz. Could you please add that while you're editing here?
Done.

Revised text:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <ins> "good" or "deactivated" </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. 6.3.2.  <ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do this when the account key is compromised. </ins>  <ins> The server MUST verify that the request is signed by the account key. If the server accepts the deactivation request, it should reply with a 200 (OK) status code and the current contents of the registration object. </ins>  <ins> Once an account is deactivated, the server MUST NOT accept further requests authorized by that account's key.  It is up to server policy how long to retain data related to that account, whether to revoke certificates issued by that account, and whether to send email to that account's contacts.  ACME does not proviate a way to reactivate a deactivated account. </ins> 6.4. If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server  <ins> deactivate each authorization associated with that identifier. The server MUST verify that the request is signed by the account key corresponding to the account that owns the authorization.  If the server accepts the deactivation, it should reply with a 200 (OK) status code and the current contents of the registration object. The server MUST NOT treat deactivated authorization objects as sufficient for issuing certificates. </ins> 6.5.