On Thu, Sep 8, 2016 at 2: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. > So what, we should just delete it? Are you arguing that this functionality is unnecessary? --Richard > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
