On Thu, Nov 12, 2015 at 4:57 PM, Daniel Kahn Gillmor <[email protected]> wrote:
> On Thu 2015-11-12 10:30:44 -0500, Matthew Holt wrote: > > If the client leaves it up to the user to follow the link, then the > format > > shouldn't matter in terms of the ACME spec; it is up to the document > > renderer (browser) to do so safely and correctly. > > if the spec has any implications that the user is agreeing to something > by proceeding with the process, then the spec needs to be really clear > what it means. If a document is unreadable by a user with (for example) > a browser that declines to execute javascript, or a browser cannot > access third-party resources, then the spec is encouraging both parties > (subscribers and CAs) to lie to each other. > > > If the client were to actually download and show the document to the > user, > > then yes, plain text would be much better. Most terminal-based clients > will > > probably not want to show the full legal terms in the terminal window, > but > > would prefer a link. Simpler, less screen space required, accomplishes > same > > goal. > > They don't appear to accomplish the same goal to me. Maybe we need to > spell out what the goal is more explicitly? > > >> b) That the resource fetched from that URL will never change. I don't > >> want to retrieve the URL at time T, display it to the user, and then > >> have the user continue the process at time T+2 when the document > >> changed at time T+1. > > > > That's the idea. The URL to that version of the document should never > > change (ideally, but I suppose that is up to the CAs), but if it does, it > > means there is a new document, i.e. updated terms, the user must agree > to. > > So the URL would be assumed to be a key or token value representing the > > actual legal text; if it changes, the user should be re-prompted. > > If the intent is to be able to update the terms of service in > continuance of the subscriber relationship, then the immutability of the > provided statement needs to be much more carefully spelled out. > > Terms of Service, notice, and consent are complex problems with effects > going all the way up the stack to layer 9. If ACME proposes to treat > them as in-scope for the specification, we need to be careful and > explicit about how they're being tied in. > > I know "the IETF does not do UI", but we need to describe at least the > semantics of tasks that the UI needs to perform on behalf of the > subscriber (or, possibly, of the CA) if we expect this additional field > to be a meaningful part of the protocol. > ISTM that what we need to do here is provide tools that will be configured by layer 9 :) There are a few basic operations to facilitate: 1. Enable the client to present the TOS to the user 2. Enable the client to indicate the user's agreement with the TOS 3. Enable the client to detect when the TOS changes 4. Enable the server to indicate when the client needs to re-agree For (1) and (3), having a URI for the terms seems sufficient, without further constraints. It's up to the CA to figure out how to present the terms in a way that clients can handle, and up to clients to figure out how to handle a reasonable array of stuff. (I expect in most cases it will get punted to a browser anyway.) For (2), we have the "agreement" field in the registration POST. I think (4) is adequately addressed by the text added in #52 ( https://github.com/ietf-wg-acme/acme/pull/52). So I'm not seeing a whole lot of need for new mechanism here. --Richard > > --dkg > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
