<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-iab-escape-report-00" indexInclude="true" ipr="trust200902" number="8752" prepTime="2020-03-11T16:39:43" scripts="Common,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-iab-escape-report-00" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8752" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ESCAPE Workshop Report">Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)</title>
    <seriesInfo name="RFC" value="8752" stream="IAB"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization showOnFrontPage="true"/>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization showOnFrontPage="true"/>
      <address>
        <email>mnot@mnot.net</email>
      </address>
    </author>
    <date month="03" year="2020"/>
    <keyword>web</keyword>
    <keyword>security</keyword>
    <keyword>origin</keyword>
    <keyword>packaging</keyword>
    <keyword>bundle</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">The Exploring Synergy between Content Aggregation and the Publisher Ecosystem
(ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in
July 2019. This report summarizes its significant points of discussion and
identifies topics that may warrant further consideration.</t>
      <t pn="section-abstract-2">Note that this document is a report on the proceedings of the 
workshop.  The views and positions documented in this report are 
those of the workshop participants and do not necessarily reflect IAB 
views and positions.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t pn="section-boilerplate.1-2">
            This document is a product of the Internet Architecture Board
            (IAB) and represents information that the IAB has deemed valuable
            to provide for permanent record.  It represents the consensus of the Internet
            Architecture Board (IAB).  Documents approved for publication
            by the IAB are not candidates for any level of Internet Standard; see
            Section 2 of RFC 7841.
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8752" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mention-of-specific-entitie">Mention of Specific Entities</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-cases">Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instant-navigation">Instant Navigation</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offline-content-sharing">Offline Content Sharing</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-other-use-cases">Other Use Cases</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.3.2">
                  <li pn="section-toc.1-1.2.2.3.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-book-publishing">Book Publishing</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.3.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.2.1"><xref derivedContent="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-web-archiving">Web Archiving</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interactions-between-web-pu">Interactions between Web Publishers and Aggregators</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-incentives-for-web-packages">Incentives for Web Packages</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-costs">Operational Costs</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-regulation">Content Regulation</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-web-performance">Web Performance</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-systemic-effects">Systemic Effects</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consolidation">Consolidation</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consolidation-of-power-in-l">Consolidation of Power in Linking Sites</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consolidation-of-power-in-p">Consolidation of Power in Publishers</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.3">
                    <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consolidation-of-user-prefe">Consolidation of User Preferences</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-effect-on-web-security">Effect on Web Security</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-of-content">Privacy of Content</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-amp-issues-unrelated-to-web">AMP Issues Unrelated to Web Packaging</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-amp-governance">AMP Governance</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-constraints-on-the-amp-form">Constraints on the AMP Format</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance">Performance</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-of-paywalls">Implementation of Paywalls</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-venues-for-future-discussio">Venues for Future Discussion</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-about-the-workshop">About the Workshop</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-agenda">Agenda</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.1.2">
                  <li pn="section-toc.1-1.9.2.1.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.9.2.1.2.1.1"><xref derivedContent="A.1.1" format="counter" sectionFormat="of" target="section-a.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-thursday-2019-07-18">Thursday 2019-07-18</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.1.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.9.2.1.2.2.1"><xref derivedContent="A.1.2" format="counter" sectionFormat="of" target="section-a.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-friday-2019-07-19">Friday 2019-07-19</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-workshop-attendees">Workshop Attendees</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-web-packaging-overview">Web Packaging Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authority-in-https">Authority in HTTPS</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authority-in-web-packaging">Authority in Web Packaging</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="B.3" format="counter" sectionFormat="of" target="section-b.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability">Applicability</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="B.4" format="counter" sectionFormat="of" target="section-b.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-amp-format-google-searc">The AMP Format, Google Search Results, and Web Packaging</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-iab-members-at-the-time-of-">IAB Members at the Time of Approval</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">The Internet Architecture Board (IAB) holds occasional workshops 
designed to consider long-term issues and strategies for the 
Internet, and to suggest future directions for the Internet 
architecture.  This long-term planning function of the IAB is 
complementary to the ongoing engineering efforts performed by working 
 groups of the Internet Engineering Task Force (IETF).</t>
      <t pn="section-1-2">The IAB convened the ESCAPE Workshop to examine some proposed changes to the Internet
and the Web, and their potential effects on the Internet publishing landscape.
Of particular interest was the Web Packaging proposal from Google, under
consideration in the IETF, the W3C's Web Incubator Community Group (WICG), and
the Web Hypertext Application Technology Working Group (WHATWG).</t>
      <t pn="section-1-3">In considering these proposals, we heard about both positive effects of Web
Packaging and concerns that it could have significant effects on the
relationship between publishers (e.g., news web sites) and content aggregators
(e.g., search engines and social networks). As such, our focus was primarily on
this relationship, rather than technical discussion.</t>
      <t pn="section-1-4">Online publishers do not regularly participate in standards activities
directly. A workshop format was used to solicit input from them. The workshop
had 27 participants from a diverse set of backgrounds, including a small number
of attendees from publishers, one aggregator (Google), plus representatives from
browsers, the Accelerated Mobile Pages (AMP) community, Content Distribution Networks (CDNs), 
network operators, academia, and standards
bodies. See the workshop call for papers <xref target="CFP" format="default" sectionFormat="of" derivedContent="CFP"/> for more information
and a complete listing of submissions.</t>
      <t pn="section-1-5">As intended, the workshop was primarily a forum for discussion, so it did not
reach definite conclusions. Instead, this report is the primary output of the
workshop, as a record of that discussion.</t>
      <t pn="section-1-6">This report documents the use cases discussed in <xref target="usecase" format="default" sectionFormat="of" derivedContent="Section 2"/> and explains the
interactions between publishers and aggregators that might be affected by it in
<xref target="tension" format="default" sectionFormat="of" derivedContent="Section 3"/>. <xref target="workshop-details" format="default" sectionFormat="of" derivedContent="Appendix A"/> includes more details about the workshop
itself. For those unfamiliar with Web Packaging, <xref target="overview" format="default" sectionFormat="of" derivedContent="Appendix B"/> provides a summary
as background material.</t>
      <section anchor="mention-of-specific-entities" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-mention-of-specific-entitie">Mention of Specific Entities</name>
        <t pn="section-1.1-1">Participants agreed to conduct the workshop under the Chatham House Rule
<xref target="CHATHAM-HOUSE" format="default" sectionFormat="of" derivedContent="CHATHAM-HOUSE"/>, so this report does not attribute statements to individuals
or organizations without express permission. Submissions to the workshop were
public and thus attributable; they are used here to provide substance and
context.</t>
      </section>
    </section>
    <section anchor="usecase" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-use-cases">Use Cases</name>
      <t pn="section-2-1">Much of the workshop concentrated on discussion of the validity and relative
merits of the use cases that might be enabled by Web Packaging. See
<xref target="overview" format="default" sectionFormat="of" derivedContent="Appendix B"/> for an overview of Web Packaging.</t>
      <section anchor="nav" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-instant-navigation">Instant Navigation</name>
        <t pn="section-2.1-1">The largest use of Web Packaging so far is in Google Search, where packages are
intended to improve the perceived performance of navigation to pages that are
linked from search results when "clicked".</t>
        <t pn="section-2.1-2">To enable this, when a linking (or referring) web page includes links to pages
on another site, it also provides the browser with a packaged copy of the target
content, signed by the origin of the target content. In effect, the referring
page provides a cache for the target page's content. If navigation to one of
those links occurs, having the Web Package gives a browser the assurance that
the cache didn't change the content, so it can treat that content as if it were
acquired directly from the server for the target page -- even though it came from
a different server. In many cases, this results in significantly lower perceived
delay in displaying the target page.</t>
        <t pn="section-2.1-3">A vital characteristic of this technique is that the browser does not contact
the target site before navigation. The browser does not make any requests to
sites until after navigation occurs, and only then if the site requires
additional content or makes a request directly.</t>
        <t pn="section-2.1-4">Similar improvements could also be realized by downloading content (packaged or
otherwise) directly from the target site through a technique called
"prefetching". However, doing so would reveal information about the user's
activity on the linking page to those sites -- even when the user never actually
navigates to it.</t>
        <aside pn="section-2.1-5">
          <t pn="section-2.1-5.1">Note: This technique that uses Web Packaging is also referred to as
"privacy-preserving prefetch". This document avoids that term as there was
some contention at the workshop about which aspects of privacy might be
preserved by the technique.</t>
        </aside>
        <t pn="section-2.1-6">Sites bundled with Web Packaging can additionally be constructed in a way that
ensures that they render without needing any additional network access. This
makes it possible to provide near-instantaneous navigation. The proposed changes
to web navigation in support of loading Web Packages is designed to support this
use case.</t>
        <t pn="section-2.1-7">Workshop participants recognized the value of web performance for usability, as
well as for business metrics like retention and bounce rates. Such improvements
were seen as a valuable goal, but publishers raised questions about whether they
justified the cost of supporting an additional format, while others raised
concerns about different aspects of the Web Packaging proposal.</t>
      </section>
      <section anchor="offline" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-offline-content-sharing">Offline Content Sharing</name>
        <t pn="section-2.2-1">Another primary use case discussed was the ability to share web content between
devices where neither has an active connection to the Internet. One of the
stated goals of Web Packaging is to enable sharing of content offline.</t>
        <t pn="section-2.2-2">Several participants reported that in areas where Internet access is expensive,
slow, or intermittent, the use of direct peer-to-peer file exchange (e.g.,
"saving a website and sharing it on a USB stick") is commonplace. Most web
browsers already have some affordances for this, but these are recognized as in
need of improvements.</t>
        <t pn="section-2.2-3">In the discussion, several rejected an assumed requirement of this
	use case -- that there be no difference between the treatment of a "normal" web page and
that of one loaded from an offline Web Package.</t>
        <t pn="section-2.2-4">The ability for a Web Package to provide clear attribution for content was seen
as valuable by some participants for a range of reasons. However, reservations
were expressed about the subtleties of the properties that signatures provide
and the effect of this on web security; see also Sections <xref target="web-sec" format="counter" sectionFormat="of" derivedContent="4.2"/> and <xref target="archive" format="counter" sectionFormat="of" derivedContent="2.3.2"/>.</t>
        <t pn="section-2.2-5">Many participants pointed out that using "unsigned bundles" -- that is, Web
Packages without signed exchanges -- could be adequate for this use case, since
most users don't need cryptographic proof of the site's identity.  However, some
expressed concerns that this might worsen the propagation of falsehood.</t>
        <t pn="section-2.2-6">Some suggested that the value of signed exchanges was not realized in
small-scale interpersonal exchange of information but in the building of
systems for content delivery that might include capabilities like discovery and
automated distribution. The contention here was that effective use of digital
signatures in offline distribution of content implied considerably more
infrastructure than was described in current proposals.</t>
        <t pn="section-2.2-7">No definite conclusions about offline sharing were reached during the workshop.</t>
      </section>
      <section anchor="other-use-cases" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-other-use-cases">Other Use Cases</name>
        <t pn="section-2.3-1">A session on the second morning concentrated on two other significant potential
use cases for Web Packages: book publishing and Web archiving. These were not
seen as "primary" by the proponents of Web Packaging; the original intent was
not to spend significant time on these subjects, but there was considerable
interest from attendees.</t>
        <section anchor="book-publishing" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1">
          <name slugifiedName="name-book-publishing">Book Publishing</name>
          <t pn="section-2.3.1-1">The potential application of a packaging format to book publishing was
discussed, with particular reference to ways that books differ from web
content. Specialists from that industry pointed out that book delivery can vary
greatly from typical web content delivery.</t>
          <t pn="section-2.3.1-2">Workshop participants briefly explored existing solutions. PDF was seen as
particularly challenging for this use case, due to its limitations, and EPUB
has constraints that also make it challenging for publishers.</t>
          <t pn="section-2.3.1-3">Although Web Packaging might help to address this use case, the question of how
to identify book content was not resolved. The use of signed exchanges in this
context might offer means of tying content in books to a website, but several
limitations inherent in doing that were identified.</t>
          <t pn="section-2.3.1-4">In particular, book publication specialists represented that books don't have
the same requirements for timeliness or currency as web pages. For instance,
Dave Cramer's submission <xref target="CRAMER" format="default" sectionFormat="of" derivedContent="CRAMER"/> observed that Moby Dick was published
over 61,000 days ago, which is considerably longer than the proposed limit of 7
days for signed exchanges. The limited length of time that a Web Package can be
considered valid was discussed at some length.</t>
          <t pn="section-2.3.1-5">Additionally, the risk of a publisher going out of business during the lifetime
of a book is significant, because books -- at least successful ones -- often span
generations in their applicability. To that end, having a means of attributing
content to a publisher was considered less practical and potentially
undesirable (much like the discussion above regarding "unsigned bundles").</t>
          <t pn="section-2.3.1-6">There were other aspects of book publication that participants saw as
challenging for packaging. For example, it is currently not understood what it
means to refer to distinct parts of a book. Participants saw this as an area where
providing stable references for bundles of content might offer possibilities,
but nothing concrete came from that discussion.</t>
          <t pn="section-2.3.1-7">The potential for active content in a bundle to use web APIs to enrich content
or enable new features was considered valuable. Models for enabling paywalls
were discussed at some length (see <xref target="paywalls" format="default" sectionFormat="of" derivedContent="Section 5.4"/>).</t>
        </section>
        <section anchor="archive" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.2">
          <name slugifiedName="name-web-archiving">Web Archiving</name>
          <t pn="section-2.3.2-1">Web archiving is a complicated discipline that is made more difficult by the
complex nature of the Web itself.</t>
          <t pn="section-2.3.2-2">From an archival standpoint, the potential for web content to be provided in a
self-contained form was viewed positively. Several improvements to the
structure of Web Packaging were considered, such as providing complete sets of
content and the use of Memento <xref target="RFC7089" format="default" sectionFormat="of" derivedContent="MEMENTO"/>.</t>
          <t pn="section-2.3.2-3">Though there were potential applications of a packaging scheme, many challenges
were recognized as requiring additional work on the part of content producers to
be fully effective. For example, JavaScript is needed to render some archived
content faithfully, but attributing that content to an origin in all scenarios
is challenging.</t>
          <t pn="section-2.3.2-4">If packaging were to be widely deployed, it might improve the situation for
archival replay. In particular, the speculation is that there would be less "live
leakage" as packaged content might be less likely to refer to live resources
that currently tend to "leak" into views of archives. It was also noted that
subresources might also be more likely to be packaged, especially those that are
needed for deferred representations (i.e., after JavaScript execution on the
page or some user interactions).  Other potential applications and enhancements
are discussed in <xref target="ALAM" format="default" sectionFormat="of" derivedContent="ALAM"/>.</t>
          <t pn="section-2.3.2-5">Participants discussed the use of a signature for non-repudiation at some
length. In one case related to the Internet Archive, a public figure disputed the
accuracy of archived content, asserting that the original content was
modified either at the source or in the archive.</t>
          <t pn="section-2.3.2-6">Some participants initially saw digital signatures as a way to address such
issues of provenance. As similar problems exist in other areas, such as in book
publication, medical research, and news, a solution to this problem was
considered to have broad applicability.</t>
          <t pn="section-2.3.2-7">However, the discussion ultimately concluded that providing non-repudiation in
retrospect is challenging. Signing keys are not expected to remain secure for
long periods. If keys are leaked afterwards, an attacker could retroactively
generate fraudulent signatures. Alternative solutions were discussed, such as
providing independent archives for the same data, using consensus protocols, or
using an append-only construct like a Haber-Stornetta log
<xref target="AOLOG" format="default" sectionFormat="of" derivedContent="AOLOG"/>, all of which can be used to increase the
difficulty of altering or misrepresenting established archives.</t>
        </section>
      </section>
    </section>
    <section anchor="tension" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-interactions-between-web-pu">Interactions between Web Publishers and Aggregators</name>
      <t pn="section-3-1">A significant motivation for holding the workshop was to provide a forum where
publishers could discuss the impact of Web Packaging on the online publishing
ecosystem. Of primary interest was whether Web Packages might effectively enable
a transfer of power from publishers to aggregators.</t>
      <t pn="section-3-2">Both publishers and aggregators at the workshop expressed the importance of
maintaining a positive relationship. Publishers in particular expressed the
need to be able to trust that aggregators won't misrepresent their work or
de-emphasize it for reasons unrelated to quality and perceived value to the
user.</t>
      <t pn="section-3-3">One key question from <xref target="BERJON" format="default" sectionFormat="of" derivedContent="BERJON"/> was discussed:</t>
      <blockquote pn="section-3-4">
      Web Packaging has other uses, but it is primarily seen by a large proportion
  of its stakeholders as a solution to problems that AMP created. Before we agree
  to solve those issues, should we not ask if AMP was a useful approach in the
  first place -- and useful to whom?
      </blockquote>
      <t pn="section-3-5">In examining this issue, discussion focused on the current incentive model
offered by aggregators. The costs that publishers incur for participation in
that system were considered. Considerable time was spent on AMP; a summary of
that discussion can be found in <xref target="conflation" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
      <t pn="section-3-6">We also considered the question of whether standardizing Web Packaging confers
credibility to aggregators exercising unwelcome control over publisher content
or whether the technical safeguards Web Packaging provides could allow
aggregators to relax their restrictions on the kinds of content they're willing
to cache and serve. No conclusions were drawn.</t>
      <section anchor="incentives-for-web-packages" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-incentives-for-web-packages">Incentives for Web Packages</name>
        <t pn="section-3.1-1">Submissions to the workshop indicated that the use of inducements involving
better placement and formatting of links to publisher content had a significant
effect on the uptake of related technology. For example, in <xref target="DEPUYDT-NELSON" format="default" sectionFormat="of" derivedContent="DEPUYDT-NELSON"/>:</t>
        <blockquote pn="section-3.1-2">
        [...] The Washington Post has always placed a great deal of trust in Google to
  represent its content--and their reward for doing so is more traffic, which
  positively impacts the business.
        </blockquote>
        <t pn="section-3.1-3">During the workshop, several online publishers indicated that if it weren't for
the privileged position in the Google Search carousel given to AMP content,
they would not publish in that format.</t>
        <t pn="section-3.1-4">Publishers that do produce AMP said they see a non-trivial increase in traffic
as a result of deploying AMP content. For example, Yahoo Japan reported a 60%
increase in traffic as a result of deploying AMP on Yahoo Travel <xref target="OTSU" format="default" sectionFormat="of" derivedContent="OTSU"/>.
There was no data presented as to whether this increase was due to better
placement in Google Search results, the inherent benefits of the AMP Cache,
or the use of the AMP format.</t>
        <t pn="section-3.1-5">Anecdotal evidence was offered by another large publisher that saw a 10% drop
in traffic as a result of accidentally disabling AMP content. However,
increases in traffic might not result in similarly proportioned increases in
revenue, as observed in <xref target="BREWSTER" format="default" sectionFormat="of" derivedContent="BREWSTER"/>.</t>
      </section>
      <section anchor="operational-costs" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-operational-costs">Operational Costs</name>
        <t pn="section-3.2-1">Several participants pointed out that introducing a new, parallel
        format for Web content incurs operational costs. In particular,
        supporting any new format -- such as Web Packaging, Apple News, or
        Facebook Instant Articles -- requires not only initial development of
        tooling (some generic and some specific to a site's requirements) but
        also an ongoing investment in maintaining its operability. Some
        participants expressed concern about the impact upon small publishers
        with limited technical and financial resources, especially in the
        current publishing climate.</t>
        <t pn="section-3.2-2">Increased exposure from new formats might not always justify the added expense
of providing articles in that format <xref target="BREWSTER" format="default" sectionFormat="of" derivedContent="BREWSTER"/>.  However, a standardized
format might help publishers reduce the cost of maintaining multiple formats.</t>
      </section>
      <section anchor="content-regulation" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-content-regulation">Content Regulation</name>
        <t pn="section-3.3-1">The use of Web Packaging as a tool for avoiding censorship was not a
significant topic of discussion, except to note that publishers often have
regulatory requirements regarding removal or correction of content.</t>
        <t pn="section-3.3-2">Reference was made to the desire to remove videos of a recent shooting
<xref target="CHRISTCHURCH" format="default" sectionFormat="of" derivedContent="CHRISTCHURCH"/> and the potential difficulty in doing so if content were
available as Web Packages. Legal requirements to remove content come from
multiple angles: copyright violations, illegal content, editorial corrections or
errors, and right to erasure provisions in the European Union General Data
Protection Regulation <xref target="GDPR" format="default" sectionFormat="of" derivedContent="GDPR"/> were mentioned.  One participant speculated that
making it more difficult to remove material in this way might discourage
regulators from censoring content.</t>
        <t pn="section-3.3-3">In this context, participants observed that it would be difficult to create
mechanisms to track and control content served as a Web Package without compromising the stated
goal of censorship resistance.</t>
      </section>
      <section anchor="web-performance" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-web-performance">Web Performance</name>
        <t pn="section-3.4-1">Understanding the effect that Web Packaging might have on web performance was a
matter of some contention.</t>
        <t pn="section-3.4-2">Some informal analysis from the Google Search deployment was presented (later
published in <xref target="AMP-PERF" format="default" sectionFormat="of" derivedContent="AMP-PERF"/>) that showed significant performance improvements in
metrics related to navigation time resulting from the combination of prefetch,
prerendering, and the AMP format.  These results are suggestive of a possibility
that Web Packaging could provide some of that improvement on its own, but no
data was presented that apportioned the improvement among the three components.</t>
        <t pn="section-3.4-3">Though data was presented to demonstrate potential rather than be a definitive
result, discussions raised a number of questions that suggest the need for
further study. Attendees suggested that future measurements consider the effect
of signed bundles distinct from the enhancements derived from the AMP
format. Future research in this area might also consider the effectiveness of
different strategies on devices with varying capabilities, bandwidth, power
consumption requirements, or network conditions.</t>
        <t pn="section-3.4-4">Of particular interest is the additional work required to fetch and render
multiple web pages in preparation for navigation.  This might ultimately use fewer
connections but comes with an increased network and CPU cost for clients. Some
participants pointed out that different clients or applications might require
different tuning -- for example, when users have limited (or expensive) bandwidth
or for sites with less clear knowledge about the use of outbound links.</t>
        <t pn="section-3.4-5">Workshop participants also expressed interest in learning about the effect of
Web Packages on subsequent navigations within the target site.</t>
        <t pn="section-3.4-6">In discussion, some participants suggested that their experience supported a
theory that operating a cache at the linking site was most effective and the
additional work done prior to navigation in terms of fetching and preparing
content was what provided the most gains; others suggested that the benefits
inherent in the AMP format was a dominant factor.</t>
        <t pn="section-3.4-7">Understanding the complete effect of Web Packaging on web performance will
require further work.</t>
      </section>
    </section>
    <section anchor="systemic-effects" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-systemic-effects">Systemic Effects</name>
      <t pn="section-4-1">It is not straightforward to estimate how a proposed technology change might
affect all of the parts of a system -- including not only other components, but
also things like end-user rights and the balance of power between parties --
ahead of time. To date, when evaluating proposals, the IETF has generally
focused on more immediate concerns, such as interoperability and security.</t>
      <t pn="section-4-2">Moreover, people often find new uses for successful standards
<xref target="RFC5218" format="default" sectionFormat="of" derivedContent="SUCCESS"/> after they are deployed. It is rarely possible to
accurately predict all applications of a protocol or format, whether they are
harmful or beneficial. Refusing standardization only impedes both outcomes.</t>
      <t pn="section-4-3">With the understanding that predictions are difficult to make, there was
considerable speculation at the workshop about the possible effect of Web
Packaging on the Web. Some of that speculation is informed by experience, but
that experience is necessarily limited in scope. This section attempts to
capture that discussion.</t>
      <section anchor="consolidation" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-consolidation">Consolidation</name>
        <t pn="section-4.1-1">Concerns about the consolidation of power on the Internet have significantly
increased lately, as a result of several factors. While the IAB, the Internet
Society, and others are examining this phenomenon to understand it better, it is
nevertheless prudent to consider whether proposals for changes to how the
Internet works favors or counters consolidation. Favoring entities with existing
advantages -- like resources, size, or market share -- is not necessarily a factor
that disqualifies a new proposal, but it needs to be considered as a cost of
enabling that technology.</t>
        <t pn="section-4.1-2">Although the outcomes of adopting Web Packaging are unclear, 
the workshop revealed several concerns for consolidation risks for all
involved parties: users, publisher sites, linking sites, and services they each
rely on.</t>
        <section anchor="consolidation-of-power-in-linking-sites" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-consolidation-of-power-in-l">Consolidation of Power in Linking Sites</name>
          <t pn="section-4.1.1-1">Several participants noted that Web Packaging's enabling of instant navigation
(<xref target="nav" format="default" sectionFormat="of" derivedContent="Section 2.1"/>) might advantage larger linking sites -- such as social networks or
search engines -- over smaller ones in the same industry because doing so
requires careful selections of which links to optimize, so as not to create
unneeded traffic.</t>
          <t pn="section-4.1.1-2">For example, a news article often has many links, but not all of them are
equally likely to be followed. Deciding which ones to prefetch requires
considerable data collection and engineering, so this technique might not be
feasible for smaller entities. Additionally, some participants noted that this
technique favors sites that have a linear set of ranked links, like search
results; it is more difficult to apply to a page of news (for example) because
predicting what link a user will follow is less obvious.</t>
          <t pn="section-4.1.1-3">This technique also requires access to a cache with terms of use compatible
with the requirements of the site. It was pointed out that the Google AMP Cache
has policies that might be acceptable to many, and there are other caches.
Sites operated by entities other than Google already use this cache, though it
was observed that a site that does not host its own cache suffers a minor
performance degradation.</t>
        </section>
        <section anchor="consolidation-of-power-in-publishers" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-consolidation-of-power-in-p">Consolidation of Power in Publishers</name>
          <t pn="section-4.1.2-1">Participants seemed to agree that if performance is a strong enough
differentiator, the effective use of Web Packaging might turn out to be a
condition for success for online publishers. Google Search's choice to
privilege content that is served using HTTPS was pointed out as showing that
this sort of influence can be effective. Equally, it is not necessarily the
case that standardization of new capabilities will affect such policies
materially, as noted in <xref target="YASSKIN" format="default" sectionFormat="of" derivedContent="YASSKIN"/>:</t>
          <blockquote pn="section-4.1.2-2">
          It seems unlikely that any decisions we make in a packaging or distribution
  system will affect the considerations aggregators use when deciding how to rank
  recommendations or the power this gives them over publishers.
          </blockquote>
          <t pn="section-4.1.2-3">The most common concern raised in the discussion was the effect of this
technology on smaller publishers who might be less able to optimize the packages
they produce, where their primary differentiation in the market has previously
been the quality of their content.</t>
        </section>
        <section anchor="consolidation-of-user-preferences" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3">
          <name slugifiedName="name-consolidation-of-user-prefe">Consolidation of User Preferences</name>
          <t pn="section-4.1.3-1">In typical operation of the Web, servers have an opportunity to tailor content
to the needs of their users. In contrast, a static Web Package has few options
for individualization, as the content is generated once and used by many.</t>
          <t pn="section-4.1.3-2">As a result, publishers noted that AMP provides less opportunity to customize
content for their customers. Their concerns included not only personalizing
content based on what they know about the user but also optimizing the package
for specific browsers. Other participants observed in relation to this that Web
Packaging might also have a consolidating effect in the browser market.</t>
          <t pn="section-4.1.3-3">Some participants brought up the possibility of customization by providing
multiple packages, including multiple variants of resources in a single package,
or performing customization after the package was loaded.  However, other
participants pointed out that all of these options have negative side effects,
either in complexity or reduced performance arising from larger bundles or
delayed customization.</t>
        </section>
      </section>
      <section anchor="web-sec" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-effect-on-web-security">Effect on Web Security</name>
        <t pn="section-4.2-1">One session explored the impact of introducing a new security model for the
Web. Currently, sites rely on connection-oriented security (provided by TLS
<xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS"/>), but Web Packaging adds a limited form of object security.
That is, the package protects the integrity of a message, rather than providing
integrity and confidentiality for its delivery. Object security is not a new
concept in the context of the Web; designs like SHTTP <xref target="RFC2660" format="default" sectionFormat="of" derivedContent="SHTTP"/> are as
old as HTTPS. Though the intent is for Web Packaging to have a far more narrow
applicability, it provides fewer security guarantees than HTTPS, since it
provides only authentication, no confidentiality with respect to the cache, and
no assurance of liveness.</t>
        <t pn="section-4.2-2">Object-based security -- such as proposed in Web Packaging -- allows the use of
content regardless of how it is obtained; some participants noted that third
parties gain greater control over the distribution of content, reducing the
ability of publishers to retract or alter content over the validity period of
signed content.</t>
        <t pn="section-4.2-3">Another topic of discussion was composition attacks. In its proposed form, Web
Packaging only provides authentication of independent resources, not a web page
as a single unit, allowing an attacker to control the composition of resources.
This weakness was acknowledged as a known shortcoming of the current proposal
that would be addressed.</t>
        <t pn="section-4.2-4">The issue of managing the trade-off between control and performance in caches
arose. While participants recognized that problems with resource composition
already occur by accident -- for example, when a cache stores different versions
of resources -- Web Packaging allows an attacker more direct control over what
resources are available to clients.</t>
        <t pn="section-4.2-5">For example, an attacker might be able to cause content with a security flaw to
be used up to a week past the time that the defect was fixed.</t>
        <t pn="section-4.2-6">As an example of how Web Packaging might change the risk profile for sites,
participants discussed recovery from cross-site scripting attacks. It is already
the case that a brief exposure to this class of attack can result in an attacker
gaining persistent access, but mechanisms exist that can be used to avoid or
correct issues, like cache validation and Clear Site Data <xref target="CLEAR-DATA" format="default" sectionFormat="of" derivedContent="CLEAR-DATA"/>. These
measures are not available to clients unless they connect to the site.</t>
        <t pn="section-4.2-7">The discussion pointed out that these concerns are not new or uniquely enabled
by Web Packaging. However, it was pointed out that new features are routinely
subject to higher security and privacy expectations. In an example unrelated to
Web Packaging but with similar trade-offs, shared compression of multiple
resources has significant performance benefits. The risk with shared compression
is the potential for exposing encrypted information through
side channels. Though sites can use shared compression without this exposure,
shared compression will likely only be enabled once it is clear that measures to
prevent accidental information exposure are understood to be effective in a
broad set of deployments.</t>
        <t pn="section-4.2-8">The discussion also addressed the question of whether concerns might equally
apply to the typical use of a CDN as a
third-party provider of the content. Some participants concluded that CDNs are
typically in a contractual relationship with the sites they serve and so are
more likely to have their interests aligned.</t>
      </section>
      <section anchor="privacy-of-content" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-privacy-of-content">Privacy of Content</name>
        <t pn="section-4.3-1">Discussion and submissions raised concerns regarding how serving content using
Web Packages might adversely affect privacy of individuals. There are
challenges here, but the very narrow applicability of Web Packaging to what is
effectively static content limits the privacy risk. The conclusion was that,
provided sufficient care is taken in implementation, the use of Web Packages does
not substantially increase the information that an aggregator gains about what
content is consumed.</t>
        <t pn="section-4.3-2">Concretely, an aggregator knows what content it serves in anticipation of
navigation. This is -- at least in theory -- substantially the same as the
content that the aggregator might receive if it performed the navigation
itself. Assuming that content is stripped of personalization, the aggregator
gains no new information.</t>
      </section>
    </section>
    <section anchor="conflation" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-amp-issues-unrelated-to-web">AMP Issues Unrelated to Web Packaging</name>
      <t pn="section-5-1">On multiple occasions, discussion at the workshop concentrated on problems that
arise as a result of constraints on the AMP format or details of its inclusion
in Google Search. For instance, the requirement to make pages expose their
metadata is unlikely to be affected by any standardization of a
packaging format as that requirement is independent of the process of
delivering content.</t>
      <t pn="section-5-2">This section provides some detail on aspects of the discussion that touched on
AMP more generally in this way. Some treatment of these points is considered
relevant as some of the discussion at the workshop, even under the remit of
discussing Web Packaging, concentrated on the effect of AMP on the ecosystem.</t>
      <aside pn="section-5-3">
        <t pn="section-5-3.1">Note: Of the four formats mentioned in the workshop call for papers
        <xref target="CFP" format="default" sectionFormat="of" derivedContent="CFP"/>, only AMP sent representatives
        to the workshop. The discussion was therefore concentrated around AMP;
        this section should not be read to imply anything about other
        formats.</t>
      </aside>
      <t pn="section-5-4">Discussion and submissions referred to a commitment <xref target="AMP-LESSONS" format="default" sectionFormat="of" derivedContent="AMP-LESSONS"/> to allow
publishers to use content that met specific criteria to access privileged
positions in search results, regardless of their adoption of AMP. Participants
felt that this approach might address some of these concerns if it were adopted
and durable. For instance, the use of Web Packaging might be sufficient to
remove some constraints on active content on the basis that the active content
would be attributed to the publisher and not the AMP Cache.</t>
      <section anchor="amp-governance" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-amp-governance">AMP Governance</name>
        <t pn="section-5.1-1">There was interest from workshop participants in the governance model used for
AMP. In particular, the question of how independent the AMP project would be of
Google and Google Search arose.</t>
        <t pn="section-5.1-2">Three of the seven members of the AMP Technical Steering Committee, the body
that governs AMP, are Google employees, which gives Google considerable
influence over the project. It was asserted that the governance structure was
intended to be more independent of Google over time. The understanding was that
any consumer of the format, such as Google Search, would make an independent
assessment about whether to use or require different aspects of the AMP project
products.</t>
      </section>
      <section anchor="constraints-on-the-amp-format" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-constraints-on-the-amp-form">Constraints on the AMP Format</name>
        <t pn="section-5.2-1">Sites often implement AMP by creating a separate set of content in parallel to
their regular HTML content. Publishers noted this as a high cost, particularly
for smaller sites. It was pointed out that websites can serve AMP-compliant
content exclusively. However, several publishers referred to limitations in the
format that made it unsuitable for their needs.</t>
        <t pn="section-5.2-2">Many cited reasons for this duplication were related to the necessity of
running arbitrary active content (typically, JavaScript). For example:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-5.2-3">
          <li pn="section-5.2-3.1">AMP provides a framework for supporting user authentication, but publishers
asserted that using this framework was not considered practical.</li>
          <li pn="section-5.2-3.2">AMP content does not support rendering of certain content, which can affect
the ability of publishers to innovate content production.</li>
          <li pn="section-5.2-3.3">The AMP model for the implementation of paywalls (<xref target="paywalls" format="default" sectionFormat="of" derivedContent="Section 5.4"/>) was claimed
to be inimical to some publisher business models.</li>
        </ul>
        <t pn="section-5.2-4">More broadly, they considered AMP's constraints on the use of active content as
problematic, since they prevent the use of capabilities that are provided on
equivalent non-AMP pages. Reference was made to a proposed &lt;amp-script&gt;
element -- which has since been made fully available -- that seeks to provide
limited access to some dynamic content.</t>
      </section>
      <section anchor="performance" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-performance">Performance</name>
        <t pn="section-5.3-1">Publishers observed that using the AMP format does not provide any guarantee of
performance gains and, in some cases, could contribute to performance
degradation. It was suggested that this was most problematic for sites that are
already well-tuned for performance.</t>
      </section>
      <section anchor="paywalls" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-implementation-of-paywalls">Implementation of Paywalls</name>
        <t pn="section-5.4-1">The use of paywalls by web publishers to control access to content in return
for payment is increasingly common. One popular approach is to offer a limited
number of articles without payment while insisting on a paid subscription to
access further articles.</t>
        <t pn="section-5.4-2">On several occasions, participants expressed dissatisfaction with the difficulty
of integrating paywall authorization when using AMP. In particular, they said
AMP encourages publishers to include an article's full content, hidden by
default but easily accessible to motivated users. 
The discussion extended to workarounds like cookie syncing <xref target="COOKIE-SYNC" format="default" sectionFormat="of" derivedContent="COOKIE-SYNC"/>,
which is used as part of authorization and is a consequence of having cached content hosted on the 
   linking site rather than the target site.</t>
        <t pn="section-5.4-3">The same topic came up concerning book publication, where publishers indicated
that having a means of enabling different methods of distribution without also
facilitating unconstrained copying of book content was necessary.</t>
        <t pn="section-5.4-4">This conflation of AMP issues with those addressed by Web Packaging was
recurrent in the discussion. As observed in <xref target="DAS" format="default" sectionFormat="of" derivedContent="DAS"/>, these concerns might be
addressed by linking to a signed bundle.</t>
      </section>
    </section>
    <section anchor="venues-for-future-discussion" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-venues-for-future-discussio">Venues for Future Discussion</name>
      <t pn="section-6-1">Web Packaging work continues in multiple forums. Questions about the
      core format and signatures are being discussed on the <eref target="https://www.ietf.org/mailman/listinfo/wpack" brackets="none">wpack@ietf.org
      mailing list</eref>. Changes to web browsers as proposed in <xref target="LOADING" format="default" sectionFormat="of" derivedContent="LOADING"/> will be discussed on the <eref target="https://github.com/whatwg/fetch/issues/784" brackets="none">Fetch specification
      repository</eref>.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-7-1">Proposals discussed at the workshop might have a significant security impact,
and these topics were discussed in some depth; see <xref target="web-sec" format="default" sectionFormat="of" derivedContent="Section 4.2"/>.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC7230" to="HTTP"/>
    <displayreference target="RFC8446" to="TLS"/>
    <displayreference target="RFC5218" to="SUCCESS"/>
    <displayreference target="RFC2660" to="SHTTP"/>
    <displayreference target="RFC7089" to="MEMENTO"/>
    <displayreference target="RFC6454" to="ORIGIN"/>
    <displayreference target="I-D.yasskin-http-origin-signed-responses" to="SXG"/>
    <displayreference target="I-D.yasskin-wpack-bundled-exchanges" to="BUNDLE"/>
    <references pn="section-8">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="ALAM" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf" quoteTitle="true" derivedAnchor="ALAM">
        <front>
          <title>Supporting Web Archiving via Web Packaging</title>
          <author initials="S." surname="Alam" fullname="Sawood Alam">
            <organization showOnFrontPage="true">Old Dominion University</organization>
          </author>
          <author initials="M." surname="Weigle" fullname="Michele C Weigle">
            <organization showOnFrontPage="true">Old Dominion University</organization>
          </author>
          <author initials="M." surname="Nelson" fullname="Michael L Nelson">
            <organization showOnFrontPage="true">Old Dominion University</organization>
          </author>
          <author initials="M." surname="Klein" fullname="Martin Klein">
            <organization showOnFrontPage="true">Los Alamos National Laboratory</organization>
          </author>
          <author initials="H." surname="Van de Sompel" fullname="Herbert Van de Sompel">
            <organization showOnFrontPage="true">Data Archiving and Networked Services</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>
      <reference anchor="AMP-LESSONS" target="https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/" quoteTitle="true" derivedAnchor="AMP-LESSONS">
        <front>
          <title>Standardizing lessons learned from AMP</title>
          <author initials="M." surname="Ubl" fullname="Malte Ubl">
            <organization showOnFrontPage="true">Google</organization>
          </author>
          <date year="2018" month="March" day="08"/>
        </front>
      </reference>
      <reference anchor="AMP-PERF" target="https://developers.googleblog.com/2019/08/the-speed-benefit-of-amp-prerendering.html" quoteTitle="true" derivedAnchor="AMP-PERF">
        <front>
          <title>The Speed Benefit of AMP Prerendering</title>
          <author initials="E." surname="Steinlauf" fullname="Eric Steinlauf">
            <organization showOnFrontPage="true">Google</organization>
          </author>
          <date year="2019" month="August" day="14"/>
        </front>
      </reference>
      <reference anchor="AOLOG" quoteTitle="true" target="https://doi.org/10.1007/bf00196791" derivedAnchor="AOLOG">
        <front>
          <title>How to time-stamp a digital document</title>
          <seriesInfo name="DOI" value="10.1007/bf00196791"/>
          <author initials="S." surname="Haber" fullname="Stuart Haber">
            <organization showOnFrontPage="true">Bellcore</organization>
          </author>
          <author initials="W." surname="Stornetta" fullname="W.Scott Stornetta">
            <organization showOnFrontPage="true">Bellcore</organization>
          </author>
          <date year="1991"/>
        </front>
        <refcontent>Journal of Cryptology, Vol. 3, Issue 2, pp. 99-111</refcontent>
      </reference>
      <reference anchor="BERJON" target="https://www.iab.org/wp-content/IAB-uploads/2019/07/NYT-ESCAPE.pdf" quoteTitle="true" derivedAnchor="BERJON">
        <front>
          <title>ESCAPE: The New York Times Position</title>
          <author initials="R." surname="Berjon" fullname="Robin Berjon">
            <organization showOnFrontPage="true">The New York Times Company</organization>
          </author>
          <date year="2019" month="July" day="09"/>
        </front>
      </reference>
      <reference anchor="BREWSTER" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/patch.pdf" quoteTitle="true" derivedAnchor="BREWSTER">
        <front>
          <title>ESCAPE Position / Patch.com</title>
          <author initials="A." surname="Brewster" fullname="Abraham Brewster">
            <organization showOnFrontPage="true">Patch.com</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>
      <reference anchor="I-D.yasskin-wpack-bundled-exchanges" quoteTitle="true" target="https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-02" derivedAnchor="BUNDLE">
        <front>
          <title>Bundled HTTP Exchanges</title>
          <author initials="J" surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="September" day="26" year="2019"/>
          <abstract>
            <t>Bundled exchanges provide a way to bundle up groups of HTTP request+response pairs to transmit or store them together.  They can include multiple top-level resources with one identified as the default by a manifest, provide random access to their component exchanges, and efficiently store 8-bit resources.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-yasskin-wpack-bundled-exchanges-02"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-yasskin-wpack-bundled-exchanges-02.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="CFP" target="https://www.iab.org/activities/workshops/escape-workshop/" quoteTitle="true" derivedAnchor="CFP">
        <front>
          <title>Exploring Synergy between Content Aggregation and the Publisher Ecosystem Workshop 2019</title>
          <author>
            <organization showOnFrontPage="true">Internet Architecture Board</organization>
          </author>
          <date year="2019" month="May" day="03"/>
        </front>
      </reference>
      <reference anchor="CHATHAM-HOUSE" target="https://www.chathamhouse.org/chatham-house-rule" quoteTitle="true" derivedAnchor="CHATHAM-HOUSE">
        <front>
          <title>Chatham House Rule</title>
          <author>
            <organization showOnFrontPage="true">Chatham House</organization>
          </author>
        </front>
      </reference>
      <reference anchor="CHRISTCHURCH" target="https://www.stuff.co.nz/business/111330323/facebook-working-around-the-clock-to-block-christchurch-shootings-video" quoteTitle="true" derivedAnchor="CHRISTCHURCH">
        <front>
          <title>'Thousands' of Christchurch shootings videos removed from YouTube, Google says</title>
          <author initials="R." surname="Stevenson" fullname="Rebecca Stevenson">
            <organization showOnFrontPage="true">Stuff Limited</organization>
          </author>
          <author initials="J." surname="Anthony" fullname="John Anthony">
            <organization showOnFrontPage="true">Stuff Limited</organization>
          </author>
          <date year="2019" month="March" day="16"/>
        </front>
      </reference>
      <reference anchor="CLEAR-DATA" target="https://www.w3.org/TR/clear-site-data/" quoteTitle="true" derivedAnchor="CLEAR-DATA">
        <front>
          <title>Clear Site Data</title>
          <author initials="M." surname="West" fullname="Mike West">
            <organization showOnFrontPage="true">Google</organization>
          </author>
          <date year="2017" month="November" day="30"/>
        </front>
        <refcontent>W3C Working Draft</refcontent>
      </reference>
      <reference anchor="COOKIE-SYNC" quoteTitle="true" target="https://doi.org/10.1145/2660267.2660347" derivedAnchor="COOKIE-SYNC">
        <front>
          <title>The Web Never Forgets</title>
          <seriesInfo name="DOI" value="10.1145/2660267.2660347"/>
          <author initials="G." surname="Acar" fullname="Gunes Acar">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Eubank" fullname="Christian Eubank">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Englehardt" fullname="Steven Englehardt">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Juarez" fullname="Marc Juarez">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Narayanan" fullname="Arvind Narayanan">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Diaz" fullname="Claudia Diaz">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014"/>
        </front>
        <refcontent>CSS '14: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 674-689</refcontent>
      </reference>
      <reference anchor="CRAMER" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/cramer-position-paper.pdf" quoteTitle="true" derivedAnchor="CRAMER">
        <front>
          <title>Packaging Books</title>
          <author initials="D." surname="Cramer" fullname="Dave Cramer">
            <organization showOnFrontPage="true">Hachette Book Group</organization>
          </author>
          <date year="2019" month="June" day="02"/>
        </front>
      </reference>
      <reference anchor="DAS" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf" quoteTitle="true" derivedAnchor="DAS">
        <front>
          <title>The Implication of Signed Exchanges on E-Commerce</title>
          <author initials="S." surname="Das" fullname="Sumantro Das">
            <organization showOnFrontPage="true">1-800-Flowers.com</organization>
          </author>
          <date year="2019" month="June" day="07"/>
        </front>
      </reference>
      <reference anchor="DEPUYDT-NELSON" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/washpost.pdf" quoteTitle="true" derivedAnchor="DEPUYDT-NELSON">
        <front>
          <title>Signed Exchanges and The Importance of Trust in Aggregator/Publisher relationships</title>
          <author initials="M." surname="DePuydt" fullname="Melissa DePuydt">
            <organization showOnFrontPage="true">The Washington Post</organization>
          </author>
          <author initials="M." surname="Nelson" fullname="Matthew Nelson">
            <organization showOnFrontPage="true">The Washington Post</organization>
          </author>
          <date year="2019" month="June" day="04"/>
        </front>
      </reference>
      <reference anchor="GDPR" target="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&amp;from=EN#d1e2606-1-1" quoteTitle="true" derivedAnchor="GDPR">
        <front>
          <title>General Data Protection Regulation</title>
          <author>
            <organization showOnFrontPage="true">European Union</organization>
          </author>
          <date year="2016" month="April" day="27"/>
        </front>
        <refcontent>EU Regulation 2016/679</refcontent>
      </reference>
      <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7230" quoteTitle="true" derivedAnchor="HTTP">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7230"/>
        <seriesInfo name="DOI" value="10.17487/RFC7230"/>
      </reference>
      <reference anchor="LOADING" target="https://wicg.github.io/webpackage/loading.html" quoteTitle="true" derivedAnchor="LOADING">
        <front>
          <title>Loading Signed Exchanges</title>
          <author initials="J." surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization showOnFrontPage="true">Google</organization>
          </author>
          <date year="2019" month="September" day="04"/>
        </front>
      </reference>
      <reference anchor="RFC7089" target="https://www.rfc-editor.org/info/rfc7089" quoteTitle="true" derivedAnchor="MEMENTO">
        <front>
          <title>HTTP Framework for Time-Based Access to Resource States -- Memento</title>
          <author initials="H." surname="Van de Sompel" fullname="H. Van de Sompel">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Nelson" fullname="M. Nelson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Sanderson" fullname="R. Sanderson">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2013" month="December"/>
          <abstract>
            <t>The HTTP-based Memento framework bridges the present and past Web.  It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps.  Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime.  TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource.  The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7089"/>
        <seriesInfo name="DOI" value="10.17487/RFC7089"/>
      </reference>
      <reference anchor="RFC6454" target="https://www.rfc-editor.org/info/rfc6454" quoteTitle="true" derivedAnchor="ORIGIN">
        <front>
          <title>The Web Origin Concept</title>
          <author initials="A." surname="Barth" fullname="A. Barth">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2011" month="December"/>
          <abstract>
            <t>This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string.  It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6454"/>
        <seriesInfo name="DOI" value="10.17487/RFC6454"/>
      </reference>
      <reference anchor="OTSU" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/shigeki-ohtsu.pdf" quoteTitle="true" derivedAnchor="OTSU">
        <front>
          <title>Deployment Experience of Signed HTTP Exchanges with AMP as a Publisher</title>
          <author initials="S." surname="Ohtsu" fullname="Shigeki Ohtsu">
            <organization showOnFrontPage="true">Yahoo Japan Corporation</organization>
          </author>
          <date year="2019" month="June" day="04"/>
        </front>
      </reference>
      <reference anchor="RFC2660" target="https://www.rfc-editor.org/info/rfc2660" quoteTitle="true" derivedAnchor="SHTTP">
        <front>
          <title>The Secure HyperText Transfer Protocol</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Schiffman" fullname="A. Schiffman">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="1999" month="August"/>
          <abstract>
            <t>This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web.  This memo defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2660"/>
        <seriesInfo name="DOI" value="10.17487/RFC2660"/>
      </reference>
      <reference anchor="RFC5218" target="https://www.rfc-editor.org/info/rfc5218" quoteTitle="true" derivedAnchor="SUCCESS">
        <front>
          <title>What Makes for a Successful Protocol?</title>
          <author initials="D." surname="Thaler" fullname="D. Thaler">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Aboba" fullname="B. Aboba">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2008" month="July"/>
          <abstract>
            <t>The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success.  It is hoped that these observations can serve as guidance for future protocol work.  This memo  provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5218"/>
        <seriesInfo name="DOI" value="10.17487/RFC5218"/>
      </reference>
      <reference anchor="I-D.yasskin-http-origin-signed-responses" quoteTitle="true" target="https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08" derivedAnchor="SXG">
        <front>
          <title>Signed HTTP Exchanges</title>
          <author initials="J" surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="November" day="4" year="2019"/>
          <abstract>
            <t>This document specifies how a server can send an HTTP exchange--a request URL, content negotiation information, and a response--with signatures that vouch for that exchange's authenticity.  These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't.  The signatures can also be used in other ways described in the appendices.  These signatures contain countermeasures against downgrade and protocol-confusion attacks.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-yasskin-http-origin-signed-responses-08"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-yasskin-http-origin-signed-responses-08.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="TAG-DC" target="https://www.w3.org/2001/tag/doc/distributed-content/" quoteTitle="true" derivedAnchor="TAG-DC">
        <front>
          <title>Distributed and syndicated content</title>
          <author initials="A." surname="Betts" fullname="Andrew Betts" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="July" day="27"/>
        </front>
        <refcontent>W3C TAG Finding</refcontent>
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="TLS">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="YASSKIN" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html" quoteTitle="true" derivedAnchor="YASSKIN">
        <front>
          <title>Chrome's position on the ESCAPE workshop</title>
          <author initials="J." surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization showOnFrontPage="true">Google</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>
    </references>
    <section anchor="workshop-details" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-about-the-workshop">About the Workshop</name>
      <t pn="section-appendix.a-1">The ESCAPE Workshop was held on 2019-07-18 and the morning of 2019-07-19 at
Cisco's facility in Herndon, Virginia, USA.</t>
      <t pn="section-appendix.a-2">Workshop attendees were asked to submit position papers. These papers
are published on the IAB website <xref target="CFP" format="default" sectionFormat="of" derivedContent="CFP"/>.</t>
      <t pn="section-appendix.a-3">The workshop was conducted under the Chatham House Rule <xref target="CHATHAM-HOUSE" format="default" sectionFormat="of" derivedContent="CHATHAM-HOUSE"/>, meaning that statements
      cannot be attributed to individuals or organizations without explicit
      authorization.</t>
      <section anchor="agenda" numbered="true" toc="include" removeInRFC="false" pn="section-a.1">
        <name slugifiedName="name-agenda">Agenda</name>
        <t pn="section-a.1-1">This section outlines the broad areas of discussion on each day.</t>
        <section anchor="thursday-2019-07-18" numbered="true" toc="include" removeInRFC="false" pn="section-a.1.1">
          <name slugifiedName="name-thursday-2019-07-18">Thursday 2019-07-18</name>
          <dl newline="false" spacing="normal" pn="section-a.1.1-1">
            <dt pn="section-a.1.1-1.1">Web Packaging Overview:</dt>
            <dd pn="section-a.1.1-1.2">
  A technical summary of Web Packaging was provided, plus a longer discussion
of a range of use cases.</dd>
            <dt pn="section-a.1.1-1.3">Web Packaging and Aggregators:</dt>
            <dd pn="section-a.1.1-1.4">
  The use of Web Packaging from the perspective of a content aggregator was
given.</dd>
            <dt pn="section-a.1.1-1.5">Web Packaging and Publishers:</dt>
            <dd pn="section-a.1.1-1.6">
  After a break, presentations from web publishers talked about the benefits
and costs of Web Packaging. This included some discussion of the effect of
developing AMP-conformant versions of content from a publisher perspective.</dd>
            <dt pn="section-a.1.1-1.7">Web Packaging and Security:</dt>
            <dd pn="section-a.1.1-1.8">
  This session concentrated on how the Web Packaging proposal might affect the
web security model.</dd>
            <dt pn="section-a.1.1-1.9">Alternatives to Web Packaging:</dt>
            <dd pn="section-a.1.1-1.10">
  This session looked at alternative technologies, including those that were
attempted in the past and some more recent ideas for addressing the use case of
making web navigations more performant.</dd>
          </dl>
        </section>
        <section anchor="friday-2019-07-19" numbered="true" toc="include" removeInRFC="false" pn="section-a.1.2">
          <name slugifiedName="name-friday-2019-07-19">Friday 2019-07-19</name>
          <dl newline="false" spacing="normal" pn="section-a.1.2-1">
            <dt pn="section-a.1.2-1.1">Web Archival:</dt>
            <dd pn="section-a.1.2-1.2">
  This session talked about the potential application of a technology like Web
Packaging in addressing some of the myriad problems faced by web archival
systems.</dd>
            <dt pn="section-a.1.2-1.3">Book Publishing:</dt>
            <dd pn="section-a.1.2-1.4">
  The effect of technologies for bundling and distribution of
books was discussed.</dd>
            <dt pn="section-a.1.2-1.5">Conclusions:</dt>
            <dd pn="section-a.1.2-1.6">
  A wrap-up session attempted to capture key takeaways from the workshop.</dd>
          </dl>
        </section>
      </section>
      <section anchor="workshop-attendees" numbered="true" toc="include" removeInRFC="false" pn="section-a.2">
        <name slugifiedName="name-workshop-attendees">Workshop Attendees</name>
        <t pn="section-a.2-1">Attendees of the workshop are listed with their primary affiliation as it
appeared in submissions. Attendees from the program committee (PC), the
Internet Architecture Board (IAB), and the Internet Engineering Steering Group
(IESG) are also marked.</t>
        <ul spacing="compact" bare="false" empty="false" pn="section-a.2-2">
          <li pn="section-a.2-2.1">
            <t pn="section-a.2-2.1.1"><contact fullname="Sawood Alam"/>, Old Dominion University</t>
          </li>
          <li pn="section-a.2-2.2">
            <t pn="section-a.2-2.2.1"><contact fullname="Jari Arkko"/>, Ericsson (IAB)</t>
          </li>
          <li pn="section-a.2-2.3">
            <t pn="section-a.2-2.3.1"><contact fullname="Richard Barnes"/>, Cisco</t>
          </li>
          <li pn="section-a.2-2.4">
            <t pn="section-a.2-2.4.1"><contact fullname="Robin Berjon"/>, New York Times (PC)</t>
          </li>
          <li pn="section-a.2-2.5">
            <t pn="section-a.2-2.5.1"><contact fullname="Zack Bloom"/>, Cloudflare</t>
          </li>
          <li pn="section-a.2-2.6">
            <t pn="section-a.2-2.6.1"><contact fullname="Abraham Brewster"/>, Patch.com</t>
          </li>
          <li pn="section-a.2-2.7">
            <t pn="section-a.2-2.7.1"><contact fullname="Alissa Cooper"/>, Cisco (IESG, IAB)</t>
          </li>
          <li pn="section-a.2-2.8">
            <t pn="section-a.2-2.8.1"><contact fullname="Dave Cramer"/>, Hachette Book Group</t>
          </li>
          <li pn="section-a.2-2.9">
            <t pn="section-a.2-2.9.1"><contact fullname="Melissa DePuydt"/>, Washington Post</t>
          </li>
          <li pn="section-a.2-2.10">
            <t pn="section-a.2-2.10.1"><contact fullname="Levi Durfee"/>, AMP Advisory Committee</t>
          </li>
          <li pn="section-a.2-2.11">
            <t pn="section-a.2-2.11.1"><contact fullname="Rudy Galfi"/>, Google</t>
          </li>
          <li pn="section-a.2-2.12">
            <t pn="section-a.2-2.12.1"><contact fullname="Joseph Lorenzo Hall"/>, Center for Democracy &amp; Technology (PC)</t>
          </li>
          <li pn="section-a.2-2.13">
            <t pn="section-a.2-2.13.1"><contact fullname="Matthew Nelson"/>, Washington Post</t>
          </li>
          <li pn="section-a.2-2.14">
            <t pn="section-a.2-2.14.1"><contact fullname="Michael Nelson"/>, Old Dominion University</t>
          </li>
          <li pn="section-a.2-2.15">
            <t pn="section-a.2-2.15.1"><contact fullname="Mark Nottingham"/>, Fastly (IAB, PC)</t>
          </li>
          <li pn="section-a.2-2.16">
            <t pn="section-a.2-2.16.1"><contact fullname="Shigeki Ohtsu"/>, Yahoo</t>
          </li>
          <li pn="section-a.2-2.17">
            <t pn="section-a.2-2.17.1"><contact fullname="Eric Rescorla"/>, Mozilla</t>
          </li>
          <li pn="section-a.2-2.18">
            <t pn="section-a.2-2.18.1"><contact fullname="Adam Roach"/>, Mozilla (IESG)</t>
          </li>
          <li pn="section-a.2-2.19">
            <t pn="section-a.2-2.19.1"><contact fullname="Rich Salz"/>, Akamai Technologies</t>
          </li>
          <li pn="section-a.2-2.20">
            <t pn="section-a.2-2.20.1"><contact fullname="Wendy Seltzer"/>, W3C</t>
          </li>
          <li pn="section-a.2-2.21">
            <t pn="section-a.2-2.21.1"><contact fullname="David Strauss"/>, Pantheon (PC)</t>
          </li>
          <li pn="section-a.2-2.22">
            <t pn="section-a.2-2.22.1"><contact fullname="Chi-Jiun Su"/>, Hughes</t>
          </li>
          <li pn="section-a.2-2.23">
            <t pn="section-a.2-2.23.1"><contact fullname="Ralph Swick"/>, W3C</t>
          </li>
          <li pn="section-a.2-2.24">
            <t pn="section-a.2-2.24.1"><contact fullname="Martin Thomson"/>, Mozilla (IAB, PC)</t>
          </li>
          <li pn="section-a.2-2.25">
            <t pn="section-a.2-2.25.1"><contact fullname="Jeffrey Yasskin"/>, Google</t>
          </li>
          <li pn="section-a.2-2.26">
            <t pn="section-a.2-2.26.1"><contact fullname="Dan York"/>, Internet Society</t>
          </li>
          <li pn="section-a.2-2.27">
            <t pn="section-a.2-2.27.1"><contact fullname="Benjamin Young"/>, John Wiley &amp; Sons</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-web-packaging-overview">Web Packaging Overview</name>
      <t pn="section-appendix.b-1">Web Packaging is comprised of two separate technologies: resource bundling
<xref target="I-D.yasskin-wpack-bundled-exchanges" format="default" sectionFormat="of" derivedContent="BUNDLE"/> and signed exchanges
<xref target="I-D.yasskin-http-origin-signed-responses" format="default" sectionFormat="of" derivedContent="SXG"/>.</t>
      <t pn="section-appendix.b-2">In both the submissions and workshop discussion, the most controversial aspect
of the technology is the use of signed exchanges as an alternative means of
providing authority over a particular resource, for a few different reasons.</t>
      <t pn="section-appendix.b-3">This appendix explains how authority works on the Web and how Web Packaging
proposes to change that.</t>
      <section anchor="authority-in-https" numbered="true" toc="include" removeInRFC="false" pn="section-b.1">
        <name slugifiedName="name-authority-in-https">Authority in HTTPS</name>
        <t pn="section-b.1-1">The Web currently uses HTTPS <xref target="RFC7230" format="default" sectionFormat="of" derivedContent="HTTP"/> to establish a server's
authority -- that is, to give an assurance that the content came from where the
URL implies. The combination of URI scheme (https), domain name (or host), and
port number are formed into a single identifier, the origin <xref target="RFC6454" format="default" sectionFormat="of" derivedContent="ORIGIN"/>
to which content is attributed.</t>
        <t pn="section-b.1-2">Web browsers use the certificate offered as part of a TLS connection
<xref target="RFC8446" format="default" sectionFormat="of" derivedContent="TLS"/> to servers in determining whether a server is authoritative
for that origin; see <xref target="RFC6454" format="default" sectionFormat="of" derivedContent="ORIGIN"/> and 
<xref target="RFC7230" section="9.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7230#section-9.1" derivedContent="HTTP"/>.
Content is attributed to a given URL only if it is received from a connection
to a server that is authoritative for the associated origin.</t>
        <t pn="section-b.1-3">As an example, a web browser seeking to load <tt>https://example.com/index.html</tt>
makes a TLS connection to a server. As part of the TLS connection
establishment, the server offers a certificate for the name <tt>example.com</tt>. If
the browser accepts the certificate, it will then make requests for URLs on the
<tt>https://example.com</tt> origin on that connection and consider any answers from the
server to be authoritative.</t>
        <t pn="section-b.1-4">This notion of authority is a crucial property of web security: only content
that is attributed to the same web origin can access all information in that
origin, including the content of most resources as well as state associated
with the origin, such as cookies. This separation ensures that sites can keep
secrets from each other, even when they are both loaded in the same browser.</t>
      </section>
      <section anchor="authority-in-web-packaging" numbered="true" toc="include" removeInRFC="false" pn="section-b.2">
        <name slugifiedName="name-authority-in-web-packaging">Authority in Web Packaging</name>
        <t pn="section-b.2-1">Web Packaging, through the use of signed exchanges, aims to provide an
alternative means of establishing authority. A signed exchange is an expression
of an HTTP request and response (an exchange) with certain information stripped
and a digital signature applied.</t>
        <t pn="section-b.2-2">The signature is made with a similar certificate to the one a server might
offer in HTTPS -- that certificate can also be used for HTTPS -- but it includes
a special attribute that denotes its suitability for signed exchanges.</t>
        <t pn="section-b.2-3">A web browser that has been provided with a signed exchange can verify the
signature and, if the signature is valid and the certificate is acceptable,
use the content from the signed exchange. Critically, the web browser does not
make an HTTPS connection to a server to get the content or to verify the
signature.</t>
        <t pn="section-b.2-4">In effect, Web Packaging moves from a model where authority is derived from the
delivery method (i.e., TLS) to an object security model, where authority is
derived from a signature on objects. In doing so, it aims to render the means
of delivery irrelevant to determinations of security.</t>
      </section>
      <section anchor="applicability" numbered="true" toc="include" removeInRFC="false" pn="section-b.3">
        <name slugifiedName="name-applicability">Applicability</name>
        <t pn="section-b.3-1">Web Packaging does not claim to supplant the authority model of the Web
completely, but it does provide an alternative that might be used under certain
narrow conditions. In particular, Web Packaging is intended for use with
content that is not secret from an entity that is aware of the existence of
that content.</t>
        <t pn="section-b.3-2">In aid of this goal, Web Packaging does not include information
   from exchanges that is related to the process of acquiring content
   nor does it include any information that is related to individual requests.
For instance, use of the
Set-Cookie header field is expressly forbidden, as it often contains
information that is related to a particular user.</t>
      </section>
      <section anchor="the-amp-format-google-search-results-and-web-packaging" numbered="true" toc="include" removeInRFC="false" pn="section-b.4">
        <name slugifiedName="name-the-amp-format-google-searc">The AMP Format, Google Search Results, and Web Packaging</name>
        <t pn="section-b.4-1">The relationship between the AMP Project <eref target="https://amp.dev/" brackets="angle"/> and Web Packaging is
complicated. The AMP Project, sponsored by Google, establishes a profile of HTML
with a stated goal of providing support for the best practices for the format,
with a strong emphasis on performance. The format tightly constrains the use of
HTML features but also offers a library of components that provide sanitized
implementations of many commonly used capabilities.</t>
        <t pn="section-b.4-2">The connection to Web Packaging is bound up in the way that Google Search
treats AMP content specially. AMP content provides two properties that Google
Search exploits: metadata exposure and static analysis of active content.</t>
        <t pn="section-b.4-3">AMP content provides metadata in a form that can be reliably extracted, using
the microformats defined by the Schema.org project <eref target="https://schema.org/" brackets="angle"/>. This
aspect of AMP has no effect on the discussion, except to the extent that this
relates to Google Search and their use of this metadata in populating the
carousel.</t>
        <t pn="section-b.4-4">Constrained use of active content -- such as JavaScript -- in AMP makes it
possible to analyze content to verify that actions taken are narrowly limited.
This static analysis assures that AMP content can be served without affecting
other content on the same site. For Google Search, this is what enables the
loading of AMP content alongside search content and other AMP resources.</t>
        <t pn="section-b.4-5">To provide preloading, Google operates the Google AMP Cache
<eref target="https://developers.google.com/amp/cache/" brackets="angle"/>, from which AMP content is served.
As a consequence, browsers attribute the content to the origin
<xref target="RFC6454" format="default" sectionFormat="of" derivedContent="ORIGIN"/> of the AMP Cache and not the publisher, creating some
confusion about how content is attributed, as discussed in the W3C finding on
distributed content <xref target="TAG-DC" format="default" sectionFormat="of" derivedContent="TAG-DC"/>.</t>
        <t pn="section-b.4-6">An important goal of Web Packaging is to attribute content loaded from a cache,
such as the Google AMP Cache, to the publisher that created that content. For more on
this, see <xref target="nav" format="default" sectionFormat="of" derivedContent="Section 2.1"/>.</t>
      </section>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-iab-members-at-the-time-of-">IAB Members at the Time of Approval</name>
      <t pn="section-appendix.c-1">Internet Architecture Board members at the time this document was approved
for publication were:</t>
      <ul empty="true" spacing="compact" bare="false" pn="section-appendix.c-2">
        <li pn="section-appendix.c-2.1">
          <t pn="section-appendix.c-2.1.1"><contact fullname="Jari Arkko"/></t>
        </li>
        <li pn="section-appendix.c-2.2">
          <t pn="section-appendix.c-2.2.1"><contact fullname="Alissa Cooper"/></t>
        </li>
        <li pn="section-appendix.c-2.3">
          <t pn="section-appendix.c-2.3.1"><contact fullname="Stephen Farrell"/></t>
        </li>
        <li pn="section-appendix.c-2.4">
          <t pn="section-appendix.c-2.4.1"><contact fullname="Wes Hardaker"/></t>
        </li>
        <li pn="section-appendix.c-2.5">
          <t pn="section-appendix.c-2.5.1"><contact fullname="Ted Hardie"/></t>
        </li>
        <li pn="section-appendix.c-2.6">
          <t pn="section-appendix.c-2.6.1"><contact fullname="Christian Huitema"/></t>
        </li>
        <li pn="section-appendix.c-2.7">
          <t pn="section-appendix.c-2.7.1"><contact fullname="Zhenbin Li"/></t>
        </li>
        <li pn="section-appendix.c-2.8">
          <t pn="section-appendix.c-2.8.1"><contact fullname="Erik Nordmark"/></t>
        </li>
        <li pn="section-appendix.c-2.9">
          <t pn="section-appendix.c-2.9.1"><contact fullname="Mark Nottingham"/></t>
        </li>
        <li pn="section-appendix.c-2.10">
          <t pn="section-appendix.c-2.10.1"><contact fullname="Melinda Shore"/></t>
        </li>
        <li pn="section-appendix.c-2.11">
          <t pn="section-appendix.c-2.11.1"><contact fullname="Jeff Tantsura"/></t>
        </li>
        <li pn="section-appendix.c-2.12">
          <t pn="section-appendix.c-2.12.1"><contact fullname="Martin Thomson"/></t>
        </li>
        <li pn="section-appendix.c-2.13">
          <t pn="section-appendix.c-2.13.1"><contact fullname="Brian Trammell"/></t>
        </li>
      </ul>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Thomson" fullname="Martin Thomson">
        <organization showOnFrontPage="true"/>
        <address>
          <email>mt@lowentropy.net</email>
        </address>
      </author>
      <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
        <organization showOnFrontPage="true"/>
        <address>
          <email>mnot@mnot.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>