- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 31 Jan 2018 12:12:38 +1100
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I don't think that any presumption of adoption is appropriate. This draft creates an entirely new interaction model that takes the process of serving a request out of the picture. Before the working group adopts this, the subject of having a request/response exchange provided to a client absent any interaction between that client and a server that is authoritative for the origin. That is, when clients no longer talk to servers, what are the ramifications for the ecosystem? It seems like this work is intended to expressly avoid engaging on that subject, but it's a huge shift for protocol interactions to effectively take authoritative servers out of the loop. The obvious argument here is that this is an extension of caching, but this takes the interactions from at least one to zero. We should first decide if it wants to engage with that issue first (I'm pleased to see some engagement already - the confidentiality facet that ekr raised is definitely worth exploring further). And then whether it wants to *do* something about it. My sense is that this is a much larger enterprise than can be contained in a mere 42 pages, so we should consider that cost and the other work we are currently pursuing. Frankly, I think that this is bigger than this working group. I think that the BoF that has been discussed probably needs to happen. Personally, I am happy to engage on the architectural issue. I have a number of reservations about the design you present, but we can talk about design once the bigger questions are addressed. On Tue, Jan 30, 2018 at 3:56 AM, Jeffrey Yasskin <jyasskin@google.com> wrote: > I've updated my signed-exchanges draft that was previously discussed at > https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0396.html. > > A list of significant changes is at > https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#change-log. > > Please look at the sections titled "Open Questions" and propose some > answers. :) > > What kinds of changes and/or reviews do you want before adopting this as a > WG draft, perhaps at IETF101? > > The one negative comment I've gotten is from Ekr, who wants clients to make > a TLS connection to the true origin (or, via the CERTIFICATE frame, to > anyone who's been issued a fake certificate) to validate the exchange. To > attempt to address this, the draft now insists that the signature's > "validityUrl" be same-origin with the claimed request URI, and > https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-02.html#seccons-downgrades > suggests that clients can fetch that URL more eagerly than just when the > signature expires. > > We have an implementation in progress in Chromium: > https://groups.google.com/a/chromium.org/d/topic/blink-dev/n7cZXSTwBTY/discussion. > > Thanks, > Jeffrey
Received on Wednesday, 31 January 2018 01:13:35 UTC