Original text:
RFC3339.  This field is REQUIRED for objects with "valid" in the "status" field. <del> If this field is present, then it MUST contain a URL for an order resource, such that this authorization is only valid for that resource.  If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. </del> 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 This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers), or to associate multiple accounts with an identifier (e.g., to allow <del> multiple entities to manage certificates).  The server may declare that an authorization is only valid for a specific order by setting the "scope" field of the authorization to the URL for that order. </del>  Authorization resources are created by the server in response to certificate orders or authorization requests submitted by an account

Reviewer comments:
It is no longer necessary with the order based issuance flow that allows the server to specify which authorizations a client must satisfy to allow issuance of an order. See URL Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back at the PR that introduced the "scope" field[0] and knowing the current state of order based issuance I'm not clear why this field is needed, or what a client could do with the scope information. Can someone clarify or should this part of the spec be removed? The server determines as a matter of policy which authorizations are required for an order and includes these in the order's array. If part of that server policy is to treat some valid authorizations as only being valid for a specific order then the server can simply not include those valid authorizations in the order's authorizations array and can instead create new pending authorizations for the client to solve. The client doesn't need to understand authorization scope it just needs to know which authorizations the server says are required and how to move these authorizations to a valid state. Since the client can't ask for specific authorizations to be used with specific orders and must react to what the server provides why is it helpful to tell a client that one of the authorizations it solved won't be used with future orders? Similarly I think the scope field interacts weirdly with pre-authorization. Are all authorization objects created with pre-authorization assumed to be global scope since they aren't associated with an order? Have any ACME clients or servers implemented order scope? Let's Encrypt/Boulder/Pebble have not. Daniel / cpu [0] - URL

Revised text:
RFC3339.  This field is REQUIRED for objects with "valid" in the "status" field.  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 This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers), or to associate multiple accounts with an identifier (e.g., to allow  <ins> multiple entities to manage certificates). </ins> Authorization resources are created by the server in response to certificate orders or authorization requests submitted by an account