Richard: You and I are in agreement about removing scope. Nobody else has voiced any concerns after two weeks. Do you think you can merge https://github.com/ietf-wg-acme/acme/pull/349 this week?
On Fri, Nov 3, 2017 at 12:26 PM, Daniel McCarney <[email protected]> wrote: > 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
