Draft: draft-ietf-acme-acme

Commentary: 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 .
Paragraph (version A):
The first phase of ACME is for the client to register with the ACME
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
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.
Paragraph (version B):
The first phase of ACME is for the client to register with the ACME
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
replying with a registration object echoing the client's input.
Paragraph (version A):
The public key of the account key pair, encoded as a JSON Web Key
object RFC7517.
Paragraph (version B):
The public key of the account key pair, encoded as a JSON Web Key
object RFC7517.  This field is not updateable by the client.
Paragraph (version A):
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.
Paragraph (version A):
A URI from which an array of URIs for application objects
submitted by this account can be fetched via a GET request.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.