That'll work - I like the idea of the meta field. No new operations seem necessary if that is present.
On Mon, Dec 28, 2015 at 3:28 PM Richard Barnes <[email protected]> wrote: > 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
