I think the TOS URI mechanism should be preserved, and the specification should be changed to state that if no new act of assent is required, the URI stored in a registration should be updated to match it automatically.
> 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. Agreed; fixing this seems desirable. > 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. My reading of the -02 spec is that a client must resubmit assent with the new URI if it ceases to match the advertised URI. > > 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. I certainly think not accepting agreement update would have been out of compliance, even if it was actually unnecessary: If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms can be accessed in a Link header with link relation "terms-of- service". As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" field, with the terms URI as its value. When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. > Very specifically, I am trying to make life easier for clients that > hardcode the agreement URL. How can hardcoding the URL ever be legitimate? You've also mentioned that agreement URI updates can never be automated, so having an in-band mechanism for agreement *update* (as opposed to initial assent at registration time) is pointless, but this isn't true. If a client user is informed of a new URI before it is deployed via an out-of-band channel, they may be able to configure their clients ahead of time to recognise and assent to it whenever they do see it. This could be automated if a large number of client instances are used; the only non-automatable work is a per-URI human-triggered approval. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
