Subject: Re: [httpwg/http-extensions] Allow servers to specify max-age in the client hints header (#306)

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Mar 2017 19:58:08 -0800

Making this a new directive in `Accept-CH` is a bit problematic, since that header field is defined as a list of header field names. It's technically possible, you just would get into situations where you have to switch your parser based upon the format of the directive, and reserve keywords that now can't be used as headers (and thus, have to register them as headers -- see `Connection`).

You *could* do it as a new header, though -- e.g.,

`Accept-CH-Lifetime: 3600`

or similar.

That has the additional benefit that it can be introduced later if there's need for it, and we decide not to do it now.

@igrigorik, what do you think? Keeping in mind that we're doing this spec primarily to document what one (albeit big) implementation is doing, hence its Experimental status, is Chrome interested in implementing this? 

If not, I'd suggest we close this issue; if it's interesting in the future, it's relatively easy to add that new header.

All of that said -- I *do* think there's a bit of an issue remaining with how the applicability of `Accept-CH` is scoped. I'll open a separate issue for that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-283549512

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Mar 2017 17:15:02 -0800

My long-term hope is that this entire discussion is a no-op and origin policy will give us the right primitives (see https://github.com/WICG/origin-policy/issues/12) to solve this in a generic way for all opt-in behaviors. That said, there *is* interest in implementing this in Chrome— tarunban@ is driving that work—and we need an alternative mechanism until OP is a thing.

I agree with Mark that `Accept-CH-Lifetime` is better solution. The secondary benefit, as I see it, is that we can also no-op it later once Origin Policy becomes available. More details in https://github.com/httpwg/http-extensions/issues/307#issuecomment-284113236.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-284113395

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Mar 2017 05:31:24 -0800

Disclaimer: I'm new here, so please forgive possible naivety :)

Thinking about this issue and other kinds of scoping mechanisms (`max-age` directives in Cache Control, Cookies or HSTS, well-known Origin Policy files etc.), I was wondering whether we could try to attach directives to manage site properties (such as CH scope) in both time "and space" to the TLS scope.

A TLS certificate is a necessary prerequisite for many HTTP/Web extensions. E.g. HSTS headers are ignored without a validated certificate. We could limit the possible lifespan of any time-bound directive to the remaining TTL of the certificate. Say my LE certificate expires in 30 days; the user  agent could store the CH settings for exactly this time span. Usually certificates are renewed before the expire. This should allow user agents to revalidate and reschedule the property expiry well before they expire. The same could apply to HSTS or other properties. A user agent may use this site/origin property until the certificate expires, and it must be revalidated at the next contact thereafter.

The spatial scope of the certificate is somewhat boring, because it usually covers a whole origin in sense of `/` on a certain domain name. However, wildcard certificates or ones with more than one common name could be used to tie together a bunch of hostnames. We could use that as an outer bound for origin properties.

More generally, could we transfer properties such as [Origin Policies](https://wicg.github.io/origin-policy/) or HSTS directives as part of the TLS handshake in an [ALPN](https://tools.ietf.org/html/rfc7301)-like fashion? This would enable the server to communicate transfer rules to the user agent before the first request on HTTP level is carried out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-284396118

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 07 Mar 2017 04:16:45 -0800

@filex interesting idea, but I don't think we want to couple certificate lifetime to other settings.. there is no reason why cert lifetime is representative of the content lifetime transported over the TLS tunnel.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-284705948

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 07 Mar 2017 19:53:11 -0800

@filex, you will find that there is a great deal of reluctance to do that sort of thing.  If we were to start doing that, then we would create another reason to lengthen the validity period of certificates.  That's bad for security.

In other words, is an *advantage* to have a logical separation of details of the authentication mechanism from the management of state.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-284939422

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 17 Mar 2017 15:28:40 -0700

First run at `Accept-CH-Lifetime`: https://github.com/httpwg/http-extensions/pull/313 - ptal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-287486917

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Mar 2017 10:31:41 -0700

Closed #306.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#event-1015748257

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Mar 2017 10:31:41 -0700

Resolved via https://github.com/httpwg/http-extensions/pull/313.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/306#issuecomment-289300715