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 `authorizations` 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] - https://github.com/ietf-wg-acme/acme/pull/124
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
