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

Reply via email to