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

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 <rlb@ipv.sx> wrote:

> On Thu, Nov 12, 2015 at 4:57 PM, Daniel Kahn Gillmor <
> dkg@fifthhorseman.net> 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
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>