Re: New version of draft-yasskin-http-origin-signed-responses-02

Hi,

+1 to Martins comments understanding the impact on the ecosystem and effort being big enough to motivate a separate WG.

In particular, the how role of the origin and there being a "secure connection" to the origin fits into the browser security framework, not only how this is 
presented in a UI or not. This area is of course the expert area of browser vendors, and more particularly, the security teams there.

The browser security model is, in my personal opinion, not finished yet though and it would be safe to assume that it will be evolving.

Thus, any changes in the what 'origin' means and how responses are delivered to a client request need to be closely coordinated with browser security framework.

This is one of the reasons why this being a task beyond what this WG could handle need to be discussed in depth.

But I do think this problem- how to securely serve a client with responses from "multiple machines" other than the one(s) initially associated fetching the web app 
is an area where more work is desirable for the evolution of the http protocol suite.

I think the draft discusses the problem from an interesting angle, useful to taking a new look on how to move the discussion forward.

I would be willing to (re)engage in the area, both about architecture and protocol extensions.

Best Regards!
Göran

On 2018-01-31, 02:17, "Martin Thomson" <martin.thomson@gmail.com> wrote:

    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.

Received on Wednesday, 31 January 2018 07:07:58 UTC