Draft: draft-ietf-acme-acme

Commentary: This is a fairly complicated part of the protocol , and not used in practice . For instance , in Let 's  's implementation , there are always three challenges , any one of which may be fulfilled by the client . After this change , all challenges are considered to be combined with an " OR . " That is , any challenge within an authorization may be completed to make the authorization valid . Authorizations within the new - application object are considered to be combined with an " AND . " That is , all of them must become valid before the certificate will be issued . The combination of the two means that we have similar expressiveness as before , even without the combinations array .
Paragraph (version A):
The challenges that the client needs to fulfill in order to prove
possession of the identifier (for pending authorizations).  For
final authorizations, the challenges that were used.  Each array
entry is a dictionary with parameters required to validate the
challenge, as specified in identifier-validation-challenges.
Paragraph (version A):
A collection of sets of challenges, each of which would be
sufficient to prove possession of the identifier.  Clients
complete a set of challenges that covers at least one set in this
array.  Challenges are identified by their indices in the
challenges array.  If no "combinations" element is included in an
authorization object, the client completes all challenges.
Paragraph (version B):
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 a dictionary with parameters required to validate the
challenge, as specified in identifier-validation-challenges.  A
client should attempt to fulfill at most one of these challenges,
and a server should consider any one of the challenges sufficient
to make the authorization valid.
Paragraph (version A):
Presumably, the client's responses provide the server with enough
information to validate one or more challenges.  The server is said
to "finalize" the authorization when it has completed all the
validations it is going to complete, and assigns the authorization a
status of "valid" or "invalid", corresponding to whether it considers
the account authorized for the identifier.  If the final state is
"valid", the server MUST add an "expires" field to the authorization.
When finalizing an authorization, the server MAY remove the
"combinations" field (if present) or remove any challenges still
pending.  The server SHOULD NOT remove challenges with status
"invalid".
Paragraph (version B):
Presumably, the client's responses provide the server with enough
information to validate one or more challenges.  The server is said
to "finalize" the authorization when it has completed all the
validations it is going to complete, and assigns the authorization a
status of "valid" or "invalid", corresponding to whether it considers
the account authorized for the identifier.  If the final state is
"valid", the server MUST add an "expires" field to the authorization.
When finalizing an authorization, the server MAY remove challenges
other than the one that was completed.  The server SHOULD NOT remove
challenges with status "invalid".