Terms of service without registration?


#1

What is the rationale for “hiding” the terms of service (ToS) behind a registration object?

There’s nothing specific to a given registration object about the ToS; it seems more sensible for it to be in the /directory, or at some other generally accessible URL.

Does Let’s Encrypt, at least, publish the ToS at any API-reliable URL that doesn’t require a registration object?


#2

Hi @FGasper,

The latest ACME specification does include the ToS in the /directory return. We don’t implement that presently but plan to. It will be bundled in with the other API breaking changes we will need to make to catch up to that spec - unfortunately we’re aware of a portion of ACME clients that treat a new but unsupported key in the directory response JSON as a hard failure.

Yes. Boulder has a /terms endpoint that returns a response with a Location: header to the ToS. It isn’t part of the ACME specification but I believe its “API-reliable” in that we don’t have any plans to get rid of it.

E.g.

$> curl -I https://acme-v01.api.letsencrypt.org/terms 2>/dev/null | grep Location
Location: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf

#3

Does ACME guarantee that the ToS as given in meta.terms-of-service (or, for Boulder, /terms) will be consistent for all registrations?

In other words, is there any reason for a client library ever to care anymore about the terms-of-service in the registration object itself given the availability of the endpoints you’ve pointed out?


#4

I’m not sure what you mean by “consistent for all registrations”. It should be the same value as returned by the new-registration endpoint. It should be updated across the board when the ToS is changed.

You need the current-most ToS for new registrations and it shouldn’t matter where you get that URL from: the directory, the /terms endpoint, or as part of the new-registration flow.

There’s a rather long and so-far inconclusive thread on the ACME mailing list to determine the future of how the ToS should be handled. I think everyone agrees the status quo isn’t ideal, its largely a question of finding a solution amenable to all parties.


#5

I’m not sure what you mean by “consistent for all registrations”. It
should be the same value as returned by the new-registration endpoint.
It should be updated across the board when the ToS is changed.

OK, I was wondering if ACME has any designs on supporting a paradigm whereby different registration objects might have different ToS. Apparently not—which simplifies life. :slight_smile:

Thanks again!


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.