I just want to add that when Jacob says "this is a field that is updated very rarely and therefore is likely to break poorly implemented clients if it changes," he is not talking about theoretical breakage. When we updated the Let's Encrypt subscriber agreement for the first time some clients broke.
On Thu, Sep 8, 2016 at 1:40 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > Restarting the conversation on > https://github.com/ietf-wg-acme/acme/pull/167. > > An earlier version of the ACME protocol treated the new-reg URL as the > entry point for all interactions. You'd configure a client with the > new-reg URL, and after creating an account, you'd get URLs for other > resources using a series of Link headers. > > This posed a problem: How do we integrate a terms-of-service URL? Our > first approach to this problem was that you get the terms-of-service URL > *after* you register, via a Link header from your registration object. > You then POST to the registration with an update. This helped reduce the > number of URLs and Link headers for clients and servers would have to be > kept track of, but it was awkward. Ideally users should agree as part of > the act of registration. Allowing accounts to be in a state where they > haven't yet agreed to the ToS means more code for both the server and > the client. > > Eventually we switched to using the directory URL as the entry point. > This solved a number of other problems with URL discovery. This also > allowed us to present the terms-of-service URL to unauthenticated users, > and made it possible to agree to the terms during account creation > rather than afterwards. > > Should we continue to model terms-of-service agreement as an updateable > field on the registration object? Emphatically no. This is not a field > that users can update, nor is it a field that we expect the server to > update frequently. In the spirit of AGL's "have one joint and keep it > well oiled" (https://www.imperialviolet.org/2016/05/16/agility.html), > this is a field that is updated very rarely and therefore is likely to > break poorly implemented clients if it changes. It's also redundant with > the terms-of-service URL that now exists in the directory. The > "agreement" field in the registration object is an accident of ACME's > history, and we should fix it before finalizing the protocol. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme -- Josh Aas Executive Director Internet Security Research Group Let's Encrypt: A Free, Automated, and Open CA _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
