Original text:
An ACME account resource represents a set of metadata associated with an account.  Account resources have the following structure: <del> The public key of the account's key pair, encoded as a JSON Web Key object RFC7517.  The client may not directly update this field, but must use the key-change resource instead. </del> The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be used to indicate user initiated deactivation whereas "revoked" a stub account object containing the "contact" field and optionally the "terms-of-service-agreed" field. <del> The server MUST ignore any values provided in the "key", and "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be provided by the client. </del>  In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect description describing the error and what types of contact URL the server considers acceptable. <del> The server creates an account and populates the account object with the "key" field containing the JWK public key used to verify the JWS. The server returns this account object in a response with a 201 (Created) status code, with the account URI in a Location header field. </del>  If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status If the client wishes to update this information in the future, it sends a POST request with updated information to the account URI. <del> The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the account object. </del>  For example, to update the contact information in the above account, the client could send the following request:

Reviewer comments:
The client knows what its public key is, because it has to have access to the private key in order to sign new-account requests or updates to the account resource. So this field serves no purpose.
Has this been discussed on list? I'm concerned that we're removing information that could be valuable for debugging client issues. There's no harm in keeping this; the server has to store this information anyway.
Yep, this was discussed on-list. I can say that as a client developer, I've never found this field useful. Clients need to be able to successfully serialize a jwk in order to speak the protocol. Also, I have no objection to servers including this as an extra field, but it seems wrong to normatively require it when it serves no purpose.
For the record where it was available for discussion. For me, the observation that you need the private key to get an account object is dispositive. There's not even debugging utility here. So I'm OK to merge. Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. URL Thoughts?

Revised text:
An ACME account resource represents a set of metadata associated with an account.  Account resources have the following structure:  The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be used to indicate user initiated deactivation whereas "revoked" a stub account object containing the "contact" field and optionally the "terms-of-service-agreed" field.  <ins> The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be provided by the client. </ins> In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect description describing the error and what types of contact URL the server considers acceptable.  <ins> The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URI in a Location header field. </ins> If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status If the client wishes to update this information in the future, it sends a POST request with updated information to the account URI.  <ins> The server MUST ignore any updates to "order" fields or any other fields it does not recognize. </ins> For example, to update the contact information in the above account, the client could send the following request: