Re: [Acme] Spec change to allow retrieval of Terms of Service URL

[Daniel Kahn Gillmor <[e-mail]>]

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.

         --dkg