Subject: [Acme] Missing rationale for the Authorization "scope" field

From: Daniel McCarney <[email-masked]>
Date: Thu, 2 Nov 2017 14:52:50 -0400

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Nov 2017 16:22:36 -0400

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-masked]> wrote:

> 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
> 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?
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 3 Nov 2017 12:26:36 -0400

> 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-masked]> 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.
>>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 17 Nov 2017 14:31:57 -0500

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?