Web Packaging
charter-ietf-wpack-00-00

The WPACK working group will develop a specification for a web packaging format
that efficiently bundles multiple HTTP resources. It will also specify a way to
optionally sign these resources such that a user agent can trust that they came
from their claimed web origins. Key goals for WPACK are:

* Efficient storage across a range of resource combinations. Three examples to
be supported are: a client-generated snapshot of a complete web page, a web
page's tree of JavaScript modules, and a selection of the whole web for
peer-to-peer distribution in a country where the internet is blocked. * The
ability to create an unsigned snapshot of a web page without the cooperation of
its publisher. * The ability to use a web app online or offline, with assurance
of its publisher, after a package of it was received from a peer. * Low latency
to load a subresource from a package, whether the package is signed or
unsigned, and whether the package is streamed or loaded from random-access
storage. * Being extensible, including to avoid cryptography that becomes
obsolete. * Security and privacy properties of using bundles as close as
practical to TLS 1.3 transport of the same resources. Where properties do
change, the group will document exactly what changed and how affected people,
including content publishers and users, can compensate. Part of this is
analyzing how the shift from transport security to object security changes the
security properties of the web's existing features. * A low likelihood
that the new format increases centralization or power imbalances on the web. *
Constraints on how clients load the formats to help achieve the above goals.

The packaging format will also aim to achieve the following secondary goals as
long as they don't compromise or delay the above properties. * Support
more-efficient signing of a single, possibly same-origin HTTP resource. *
Support signed statements about subresources beyond just assertions that
they're accurate representations of particular URLs. * Address the threat
model of a website compromised after a user first uses the site. * Support
books being published in the format. * Support long-lived archival storage. *
Optimize transport of large numbers of small same-origin resources. * Allow the
format to be used in self-extracting executables. * Allow publishers to
efficiently combine sub-packages from other publishers.

The following potential goals are out of scope under this charter:
* DRM
* A way to distribute the private portions of a website. For example, WPACK
might define a way to distribute a messaging application but wouldn't
define a way to distribute individual messages without a direct connection to
the messaging application's origin server. * Defining the details of how
web browsers load the formats and interact with any protocols we define here,
aside from the constraints mentioned above. * A way to automatically discover
the URL for an accessible package that includes specific content.

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set (consisting of
draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and
draft-yasskin-http-origin-signed-responses) does not imply that there is
consensus around the feature or around how it is specified.

Relationship to Other WGs and SDOs

WPACK will work with the W3C and WHATWG to identify the existing security and
privacy models for the web, and to ensure those SDOs can define how this format
is used by web browsers.