I think the intent when we implemented it was to communicate to clients that an authz was only good for a single issuance, so that if a client was doing pre-authorization, they would know that that authorization wouldn't be reused.
Given that all issuance now goes through new-order, it's probably safe to remove this. If the client guesses wrong about what authz it needs, the server can tell it what else it needs to do. --Richard On Thu, Nov 2, 2017 at 2:52 PM, Daniel McCarney <[email protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
