Hi Jonathan, However, the authorizations array appears to be documented as changing > between the pending and final states, which would make it mutable.
I think the section that you quote next isn't very clear, but the array of URLs is in-fact immutable. I believe it is just describing that for a pending order, the authz URLs are expected to point to status: pending authorizations, and for a final order, the authz URLs are expected to point to status: final authorizations. The array of URIs itself should remain unchanged between the authorizations changing state. I will try and clarify that text slightly. - Daniel / cpu On Sun, Jan 7, 2018 at 1:29 PM, Jonathan Rudenberg <[email protected]> wrote: > I just came across what appears to be a minor inconsistency around the > mutability of the order object’s authorizations array. > > Section 7.1.3 (Order Objects), says: > > > The elements of the "authorizations" and "identifiers" array are > > immutable once set. The server MUST NOT change the contents either > > array after they are created. If a client observes a change in the > > contents of either array, then it SHOULD consider the order invalid. > > However, the authorizations array appears to be documented as changing > between the pending and final states, which would make it mutable. > > > authorizations (required, array of string): For pending orders, the > > authorizations that the client needs to complete before the > > requested certificate can be issued (see Section 7.5). For final > > orders (in the "valid" or "invalid" state), the authorizations > > that were completed. Each entry is a URL from which an > > authorization can be fetched with a GET request. > > Jonathan > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
