The following feedback is based on 8010a31 (current HEAD of master).

Section 7.3.1, Changes of Terms of Service, states the following:

"As described above, a client can indicate its agreement with the CA’s terms of 
service by setting the “terms-of-service-agreed” field in its account object to 
“true”.

"If the server has changed its terms of service since a client initially 
agreed, and the server is unwilling to process a request without explicit 
agreement to the new terms, then it MUST return an error response with status 
code 403 (Forbidden) and type “urn:ietf:params:acme:error:userActionRequired”. 
This response MUST include a Link header with link relation “terms-of-service” 
and the latest terms-of-service URL.

"The problem document returned with the error MUST also include an “instance” 
field, indicating a URL that the client should direct a human user to visit in 
order for instructions on how to agree to the terms."


I realize that this has been debated extensively and largely agree with the 
conclusions from [1], but I think there are disadvantages to having the ToS URL 
provide instructions for the human user to agree to the new term. The main 
concern I have with [1] is that there may not be a clear way for the human user 
to authenticate with the CA to click an "Accept" button if the ACME server 
hasn't needed to use the external-account-binding functionality for some other 
reason.


I think a relatively small change could address this: associate a timestamp 
with terms-of-service-agreed, and include it as a read-only part of the account 
object.

In this way, it is easy for a client to allow the human user to re-accept terms 
in a standard way (following the same pattern the client would use for any 
other account update), causing the server to update the associated timestamp. 
This provides consistency between ACME servers.

This requires that the server track when clients have agreed to updated terms 
of service, which is only incrementally more work than storing a boolean (and 
is something a server may want to track anyway).


This still fully supports the notion of "auto updating" terms of service.

This could still support a human user clicking an "Accept" button, which could 
trigger an out-of-band update to the timestamp (and the permissibility of this 
could be emphasized with a MAY).

This adds minimal additional complexity to the protocol.

Regards,
Zach Shepherd

1 - https://mailarchive.ietf.org/arch/msg/acme/c-wycMyvyX0Jkk7NS0Lfxj6Z0GY

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to