Contact emails
Eng: kin...@chromium.org, kou...@chromium.org, ho...@chromium.org
Spec: jyas...@chromium.org
Explainer
No explainer specific to Origin-Signed HTTP Exchanges yet (Jeffrey will have one up soon).
In the meantime, see a sample of use cases for Origin-Signed HTTP exchanges and the broader context from the Web Packaging explainer (https://github.com/WICG/webpackage/blob/master/explainer.md).
Design doc/Spec
Spec:
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
(We will have additional spec(s) for the application/http-exchange+cbor format and its loading)
Design Doc:
https://docs.google.com/document/d/1zXEGCl3GI4JShJFkwq_7jsIcxJNjlPUgb0RW2Flqt-c
Related tag review links:
https://www.w3.org/2001/tag/doc/distributed-content/
https://github.com/w3ctag/packaging-on-the-web/blob/gh-pages/README.md
Note that the TAG has not specifically reviewed the current iteration of the proposal.
IETF DISPATCH WG feedback:
https://datatracker.ietf.org/doc/minutes-99-dispatch/
Summary
Support origin-signed HTTP Exchanges in Chrome’s loading pipeline, so that signed Web documents can be loaded and navigated as if they came from particular origins regardless of where they are actually served from.
Initially, we will only support signed exchanges wrapped in the application/http-exchange+cbor envelope format. Each application/http-exchange+cbor envelope will have single signed exchange.
Motivation
WebPackaging opens up various compelling use cases, including offline peer-to-peer webapp sharing, web publications, and integrity-preserving distribution of content from non-authoritative server. The HTTP working group recommended that this be split up into two layers: a way to sign individual request/response pairs, and a way to bundle several such exchanges. This Intent is for the first layer, which supports distribution and an improvement to how we attribute AMP content to the right origin.
Risks
Interoperability and Compatibility
High (early spec stages)
Edge: No public signals
Firefox: No public signals
Safari: Public skepticism: https://twitter.com/othermaciej/status/950997728275804160
Web developers: Multiple publishers, teams, projects and AMP are showing interest.
Security
The draft lists several security concerns, especially that this relaxes the on-path restriction for attackers with an illegitimate certificate, and that this allows attackers to use buggy code for a period after it's fixed on the real server. Thorough discussions with security experts are happening and we expect to have more of those as we make progress.
Ergonomics
This will often be used with prefetch and eventually HTTP/2 Push. The signed exchange format assumes its validator can initiate a fetch for the certificate, which may be difficult if the validator is inside the network layer.
Publisher serve a signed exchange by serving a normal response plus Signed-Headers and Signature headers.
Distributors can forward a signed exchange either by HTTP/2 Pushing it (not supported in our initial implementation) or by linking to an application/http-exchange+cbor resource.
Activation
We will provide a tool publishers can run to create the Signature header or the wrapped resource, using their TLS private key.
Debuggability
We will need (at least) following features integrated in DevTools:
[P1] Network panel shows recursive prefetches for resources referred to from inside a prefetched signed HTTP exchange.
[P2] Clicking a response holding a signed HTTP exchange should show the content of CBOR envelope, including the certificate, signature, and whether the signature is valid.
(There could be possibly more)
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux, Chrome OS and Android will be covered.
Android WebView is still TBD
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5745285984681984
Requesting approval to ship?
No
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30cffa39-01cd-4140-b65e-d046cb161d4b%40chromium.org.