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:
> 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
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
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
Acme mailing list