Draft: draft-ietf-acme-acme

Commentary: This pull request includes changes to : Consistently use " header parameter " when referring to JWS header parameters .  a missing right curly bracket in a section reference . Use " server - initiated " instead of " administratively initiated " for clarity . Use parallel sentence structure for clarity / readability .
Paragraph (version A):
As noted in request-authentication above, all ACME request objects
carry a "url" parameter in their protected header.  This header
parameter encodes the URL to which the client is directing the
request.  On receiving such an object in an HTTP request, the server
MUST compare the "url" parameter to the request URL.  If the two do
not match, then the server MUST reject the request as unauthorized.
Paragraph (version A):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  For these resources,
the client MUST set the "url" field to the exact string provided by
the server (rather than performing any re-encoding on the URL).  The
server SHOULD perform the corresponding string equality check,
configuring each resource with the URL string provided to clients and
having the resource check that requests have the same string in their
"url" fields.
Paragraph (version A):
The "url" header parameter specifies the URL RFC3986 to which this
JWS object is directed.  The "url" parameter MUST be carried in the
protected header of the JWS.  The value of the "url" header MUST be a
string representing the URL.
Paragraph (version B):
As noted in request-authentication above, all ACME request objects
carry a "url" header parameter in their protected header.  This
header parameter encodes the URL to which the client is directing the
request.  On receiving such an object in an HTTP request, the server
MUST compare the "url" header parameter to the request URL.  If the
two do not match, then the server MUST reject the request as
unauthorized.
Paragraph (version B):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  For these resources,
the client MUST set the "url" header parameter to the exact string
provided by the server (rather than performing any re-encoding on the
URL).  The server SHOULD perform the corresponding string equality
check, configuring each resource with the URL string provided to
clients and having the resource check that requests have the same
string in their "url" header parameter.
Paragraph (version B):
The "url" header parameter specifies the URL RFC3986 to which this
JWS object is directed.  The "url" header parameter MUST be carried
in the protected header of the JWS.  The value of the "url" header
parameter MUST be a string representing the URL.
Paragraph (version A):
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"
should be used to indicate administratively initiated
deactivation.
Paragraph (version B):
The status of this account.  Possible values are: "valid",
"deactivated", and "revoked".  The value "deactivated" should be
used to indicate client-initiated deactivation whereas "revoked"
should be used to indicate server-initiated deactivation.
Paragraph (version A):
The challenges that the client can fulfill in order to prove
possession of the identifier (for pending authorizations).  For
final authorizations, the challenges that were used.  Each array
entry is an object with parameters required to validate the
challenge.  A client should attempt to fulfill one of these
challenges, and a server should consider any one of the challenges
sufficient to make the authorization valid.  For final
authorizations it contains the challenges that were completed.
Paragraph (version B):
For pending authorizations, the challenges that the client can
fulfill in order to prove possession of the identifier.  For final
authorizations, the challenges that were used.  Each array entry
is an object with parameters required to validate the challenge.
A client should attempt to fulfill one of these challenges, and a
server should consider any one of the challenges sufficient to
make the authorization valid.  For final authorizations it
contains the challenges that were completed.
Paragraph (version A):
The inner JWS MUST have the same "url" parameter as the outer JWS.
Paragraph (version A):
The inner JWS is NOT REQUIRED to have a "nonce" parameter.  The
server MUST ignore any value provided for the "nonce" header
parameter.
Paragraph (version B):
The inner JWS MUST have the same "url" header parameter as the
outer JWS.
Paragraph (version B):
The inner JWS is NOT REQUIRED to have a "nonce" header parameter.
The server MUST ignore any value provided for the "nonce" header
parameter.