On 09/17/2016 02:08 AM, Ron wrote: > > And if the answer to that is "we do automate it", then the important > question is: Does this even remotely satisfy the actual requirement? IANAL, but the feedback we've gotten so far is it is reasonable for someone to agree to terms of service through an API.
There are a lot of philosophical issues of what it means to signal agreement via an API, since we don't ultimately control all the clients that get written. It will always be possible for someone to write code that auto-agrees to certain terms of service. Such software may even be written in good faith. For instance, if you've read the terms of service, and want to install software on hundreds of machines that agrees to those terms, the software doesn't need to prompt you every time. However, having to be explicit about the agreement, whether through a flag or a URL, means that the client author is more likely to at least make an explicit decision about how and when to present the terms of service to the user. > AIUI the CABF requirement is for an explicit agreement that is legally > binding to the end user in the applicable jurisdiction. > > The problem you ran into with the existing system is that some (many? > all?) extant clients simply hardcoded: > > "agreement":"https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf"; > > into their source, without even looking at what the directory reported. > And that others required user intervention before performing the actions > to accept a changed ToS URL. > > And the solution you are proposing to 'fix' that is for them to instead > hardcode "agreement":"yes", so that it still 'works' no matter what > random text is indicated in the directory at any point in time - and so > that doing it once implicitly agrees to any future ToS in advance. I think this may be where we are not understanding each other. This is not the main problem I am trying to fix. I'm trying to fix: 1. Registration is a two-step process, when it only needs to be one. 2. Accounts can be created without agreeing to terms, which creates an unnecessary indeterminate state. 3. The protocol hints at the idea that the client could post new terms of service URLs to the registration object, without specifying anything about when it is permissible, when it is required, or what actions the server should take on update. 4. Similarly, the protocol doesn't make clear whether the server should automatically update the terms of service URL stored in the registration object. Some of the problems we saw: - Clients that expected the terms of service URL in existing registration objects to match the current directory, and failing if not. - Clients attempting to POST the new terms of service URL to update their registration object, even though that was unnecessary and unsupported by Boulder at the time. We added support to un-break these clients. Very specifically, I am trying to make life easier for clients that hardcode the agreement URL. I am proposing it because it removes parts of the protocol that are unnecessary and have proven to be confusing. > be harder and uglier to fix that later than if we just punted on this > and did nothing at all. "Do nothing" is not an option. We need to either decide on new logic for (3) and (4), and add that to the spec, along with all the attendant complexity, or we can adopt the simpler agreement protocol that I am proposing. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
