> 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.
Sounds good to me. Here's a PR to do so: https://github.com/ietf-wg-acme/acme/pull/349 - Daniel / cpu On Thu, Nov 2, 2017 at 4:22 PM, Richard Barnes <[email protected]> wrote: > 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
