Original text:
6.3.2.  A client may wish to change the public key that is associated with a account in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.

Reviewer comments:
This is a variant of that uses a MAC key to perform the account binding instead of a bearer token. Thanks to NAME for pointing out the need for this on the ACME mailing list.
Question: will you require a CA that doesn't use external account bindings to reject a request if it contains an external-account-binding member? nit: s/field/member/g, consistent with RFC 7159.
StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the URL account that send this token to the email address used in the registration. At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level. After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL. please add this a parameter to the ACME protocol, thanks.
This request should be sent to the ACME mailing list (EMAIL) for further discussion, it would also be very useful to know what your EV (or OV) validation flow would look like using ACME as most likely the current certificate application object would need to be changed to identify those requirements to the server.
This was fixed by
Minor editorial comments.

Revised text:
6.3.2. <ins> The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url- encoded form, to maximize compatibility between provisioning systems and ACME clients. The ACME client then computes a binding JWS to indicate the external account's approval of the ACME account key.  The payload of this JWS is the account key being registered, in JWK form.  The protected header of the JWS MUST meet the following criteria: The "alg" field MUST indicate a MAC-based algorithm The "kid" field MUST contain the key identifier provided by the CA The "nonce" field MUST NOT be present The "url" field MUST be set to the same value as the outer JWS The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. When a CA receives a new-registration request containing an "external-account-binding" field, it must decide whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT reflect the "external-account-binding" field in the resulting account object (if any).  To verify the account binding, the CA MUST take the following steps: Verify that the value of the field is a well-formed JWS Verify that the JWS protected meets the above criteria Retrieve the MAC key corresponding to the key identifier in the "kid" field Verify that the MAC on the JWS verifies using that MAC key Verify that the payload of the JWS represents the same key as was used to verify the outer JWS (i.e., the "jwk" field of the outer JWS) If all of these checks pass and the CA creates a new account, then the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If any of these checks fail, then the CA MUST reject the new- registration request. 6.3.3. </ins> A client may wish to change the public key that is associated with a account in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.