Code change:
There has been no implementer interest in the proof-of-possession challenge, and it makes the document more complex by having a completely different structure than the other challenges. If it is decided later that such a challenge is necessary, it can be added in a follow-on extension specificiation.
Generally this seems fine, and I wholeheartedly agree with the purpose of the removal (for now). One problem I can't open a comment for: Line 2099, the last paragraph before "Preventing Authorization Hijacking", still refers to the PoP Challenge. Without the PoP Challenge wording, a new reader may take that this to be referring to the implicit Proof of Possession of the ACME Account Key and thus be confused. Since it's non-normative, perhaps you could simply modify that paragraph into something more like:

Related discussion:
text: 7.4. <del> The Proof of Possession challenge verifies that a client possesses a private key corresponding to a server-specified public key, as demonstrated by its ability to sign with that key.  This challenge is meant to be used when the server knows of a public key that is already associated with the identifier being claimed, and wishes for new authorizations to be authorized by the holder of the corresponding private key.  For DNS identifiers, for example, this can help guard against domain hijacking. This method is useful if a server policy calls for issuing a certificate only to an entity that already possesses the subject private key of a particular prior related certificate (perhaps issued by a different CA).  It may also help enable other kinds of server policy that are related to authenticating a client's identity using digital signatures. This challenge proceeds in much the same way as the proof of possession of the authorized key pair in the main ACME flow (challenge + authorizationRequest).  The server provides a nonce and the client signs over the nonce.  The main difference is that rather than signing with the private key of the key pair being authorized, the client signs with a private key specified by the server.  The server can specify which key pair(s) are acceptable directly (by indicating a public key), or by asking for the key corresponding to a certificate. The server provides the following fields as part of the challenge: The string "proof-of-possession-01" An array of certificates, in base64url-encoded DER format, that contain acceptable public keys. In response to this challenge, the client uses the private key corresponding to one of the acceptable public keys to sign a JWS object including data related to the challenge.  The validation object covered by the signature has the following fields: The string "proof-of-possession" A list of identifiers for which the holder of the prior key authorizes the new key The client's account public key This JWS is NOT REQUIRED to have a "nonce" header parameter (as with the JWS objects that carry ACME request objects).  This allows proof- of-possession response objects to be computed off-line.  For example, as part of a domain transfer, the new domain owner might require the old domain owner to sign a proof-of-possession validation object, so that the new domain owner can present that in an ACME transaction later. The validation JWS MUST contain a "jwk" header parameter indicating the public key under which the server should verify the JWS. The client's response includes the server-provided nonce, together with a signature over that nonce by one of the private keys requested by the server. The string "proof-of-possession" The validation JWS To validate a proof-of-possession challenge, the server performs the following steps: Verify that the public key in the "jwk" header of the "authorization" JWS corresponds to one of the certificates in the "certs" field of the challenge Verify the "authorization" JWS using the key indicated in its "jwk" header Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object, and that: * The "type" field is set to "proof-of-possession" * The "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued If all of the above verifications succeed, then the validation is successful.  Otherwise, the validation fails. 7.5. </del> When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a resource record under it.  The DNS challenge requires the client to provision a TXT record