Change:
This mitigates confusion about how clients should respond when terms of service change.
Updated based on review. Took out the echoing of the field on subsequent requests, because it makes things simpler and clearer.

Discussion:
server.  The client generates an asymmetric key pair and associates this key pair with a set of contact information by signing the contact information.  The server acknowledges the registration by <del> replying with a registration object echoing the client's input.  The server can also provide terms of service at this stage, which the client can present to a human user. </del> <ins> replying with a registration object echoing the client's input. </ins> Once the client is registered, there are three major steps it needs to take to get a certificate:

structure: The public key of the account key pair, encoded as a JSON Web Key <del> object RFC7517. </del> <ins> object RFC7517.  This field is not updateable by the client. </ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to

issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. <del> A URI referring to a subscriber agreement or terms of service provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. </del> <ins> Including this field in a new-registration request, with a value of true, indicates the client's agreement with the terms of service.  This field is not updateable by the client. </ins> <del> A URI from which an array of URIs for application objects submitted by this account can be fetched via a GET request. </del> <ins> A URI from which a list of authorizations submitted by this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries.  This field is not updateable by the client. </ins> 6.1.2.1.

If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms <del> can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" field, with the terms URI as its value.  When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. </del> <ins> can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server SHOULD reject new- registration requests that do not contain "terms-of-service-agreed": true. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration