Change:
This is a fairly complicated part of the protocol, and not used in practice. For instance, in Let's Encrypt'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.

Discussion:
consider this authorization valid for all applications until the authorization expires. [[ Open issue: More flexible scoping? ]] <del> The challenges that the client needs to fulfill in order to prove </del> <ins> The challenges that the client can fulfill in order to prove </ins> 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 <del> challenge, as specified in identifier-validation-challenges. 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. </del> <ins> 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. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier

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. <del> 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". </del> <ins> 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". </ins> Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is

"http-05" - but not one labeled "http-04", since challenge in version -04 was compatible with one in version -04. ]] <del> [[ Editor's Note: Operators SHOULD NOT issue "combinations" arrays in authorization objects that require the client to perform multiple challenges over the same type, e.g., ["http-03", "http-05"]. Challenges within a type are testing the same capability of the domain owner, and it may not be possible to satisfy both at once. ]] </del> 7.1. Several of the challenges in this document makes use of a key