* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Wpack Status Pages

Web Packaging (Active WG)
Art Area: Barry Leiba, Murray Kucherawy | 2020-Mar-24 —  
Chairs
 
 


2020-03-26 charter

Web Packaging (wpack)
---------------------

 Charter

 Current Status: Active

 Chairs:
     David C Lawrence <tale@dd.org>
     Sean Turner <sean+ietf@sn3rd.com>

 Applications and Real-Time Area Directors:
     Murray Kucherawy <superuser@gmail.com>
     Barry Leiba <barryleiba@computer.org>

 Applications and Real-Time Area Advisor:
     Murray Kucherawy <superuser@gmail.com>

 Mailing Lists:
     General Discussion: wpack@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/wpack
     Archive:            https://mailarchive.ietf.org/arch/browse/wpack/

Description of Working Group:

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

  * Efficient (binary) storage across a range of resource combinations. Three use cases 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 when access to authoritative servers is unavailable.

  * The ability to create a snapshot of a web page without the cooperation of its publisher.

  * The ability to receive a web package from an entity other than the origin server and have continuity of experience and state (especially that created by active content such as JavaScript) between the offline and online versions.

  * When a bundle is streamed, the client must be able to start using a subresource before the entire bundle is downloaded, and for large subresources, before the entire subresource is downloaded.

  * When a bundle is loaded from random-access storage, the client must be able to use a subresource without necessarily reading the entire prefix of the bundle before that subresource.

  * When a bundle is authenticated, the client must be able to validate the authentication without extra requests over the network.

  * Being extensible and crypto agile.

  * Security and privacy properties of using authenticated 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.

  * Specifying constraints on how clients load the formats without describing specific loading algorithm 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.

  * Optimizations in encoding and processing when only a single resource (as opposed to a collection thereof) is being packaged

  * Support signed statements about subresources beyond just assertions that they're accurate representations of particular URLs.

  * Address the threat model of a website's frontend compromised after a user first uses the site.

  * Support books being published in the format: support for bundles that have no expiration date; ability to reference a resource withing a bundle (e.g. chapter)

  * Optimize storage of large numbers of small same-origin resources (e.g. using compression)

  * Allow publishers to efficiently combine sub-packages from other publishers.

  The following goals are out of scope under this charter:

  * DRM (Digital Rights Management)

  * 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.

  * A way to automatically discover the URL for an accessible (retrievable) package that includes specific content.

  Note that consensus is required both for changes to the initially proposed protocol mechanisms and for their retention. In particular, because something is in an initial working group draft 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.

  The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing.


Goals and Milestones:
  Jun 2020 - Working group adoption of use cases document (will not be published as an RFC)
  Jun 2020 - Working group adoption of bundling document
  Jun 2020 - Working group adoption of security analysis document
  Jun 2020 - Working group adoption of privacy analysis document
  Jun 2020 - Working group adoption of one or more signing document
  Sep 2021 - Submit the Bundling document to IESG
  Mar 2022 - Submit the Privacy analysis document to IESG
  Mar 2022 - Submit the Security analysis document to IESG
  Mar 2022 - Submit Signing document (this might just reference HTTPBIS work) to IESG


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/wpack/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -