Internet DRAFT - draft-thomson-wpack-content-origin
draft-thomson-wpack-content-origin
wpack M. Thomson
Internet-Draft Mozilla
Updates: 6454 (if approved) 9 March 2020
Intended status: Standards Track
Expires: 10 September 2020
Content-Based Origins for the Web
draft-thomson-wpack-content-origin-00
Abstract
Making content available to clients that are unable or unwilling to
contact a web origin enables new means of acquiring content. This
document describes a method for taking application state accumulated
by an offline user agent in relation to a piece of content and making
that state available in a fully online context. This enables
continuous use of content, starting from a state where the user agent
does not contact an origin and ending with
This document proposes an update to the definition of Origin in RFC
6454. It also proposes changes that would affect HTML, which is
outside of the remit of the IETF.
Note to Readers
Discussion of this document takes place on the WPACK Working Group
mailing list (wpack@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/wpack/
(https://mailarchive.ietf.org/arch/browse/wpack/).
Source for this draft and an issue tracker can be found at
https://github.com/martinthomson/wpack-content
(https://github.com/martinthomson/wpack-content).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Thomson Expires 10 September 2020 [Page 1]
Internet-Draft Content-Based Origins March 2020
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 September 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) 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. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview and Comparisons . . . . . . . . . . . . . . . . . . 4
3.1. Offline-to-Online Transition for Content-Based Origins . 4
3.2. Offline-to-Online Transition for Signed Exchanges . . . . 5
3.3. Comparison with Signed Exchanges . . . . . . . . . . . . 7
3.4. Comparison with Unsigned Bundles . . . . . . . . . . . . 7
4. Content-Based Origin Definition . . . . . . . . . . . . . . . 8
4.1. Content Type Malleability . . . . . . . . . . . . . . . . 9
4.2. Hash Agility . . . . . . . . . . . . . . . . . . . . . . 9
5. Transfer to HTTPS Origin . . . . . . . . . . . . . . . . . . 10
5.1. Successful Transfer . . . . . . . . . . . . . . . . . . . 10
5.2. Unsuccessful Transfer . . . . . . . . . . . . . . . . . . 11
5.3. Transfer Target . . . . . . . . . . . . . . . . . . . . . 12
5.4. State Transfer . . . . . . . . . . . . . . . . . . . . . 12
5.4.1. Transfer of Content . . . . . . . . . . . . . . . . . 13
5.4.2. Transfer of Storage . . . . . . . . . . . . . . . . . 13
5.4.3. Transfer of Permissions . . . . . . . . . . . . . . . 14
5.5. Navigation Transfers . . . . . . . . . . . . . . . . . . 14
5.6. Communication Between Origins . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Thomson Expires 10 September 2020 [Page 2]
Internet-Draft Content-Based Origins March 2020
1. Introduction
The web relies on the concept of origins [ORIGIN] as the primary
means of identification for resources. A strongly authenticated
HTTPS origin is the basis for many security decisions. However,
establishing this identity relies on having an active TLS [TLS]
connection to a server that is considered authoritative for the
origin; see Section 11 of [HTTP].
A user agent that is offline when content is received cannot
establish this authority. Similarly, a user agent might be unwilling
to contact a server at the time that content is received. One reason
for not contacting a server might be to avoid leaking information
about the context in which content was referenced. In either case,
content cannot be attributed to the origin at the time it is
received.
In operation, content might be delivered by any means other than a
TLS connection to the intended server. Then there might be a period
during which the content is used. For instance, the content might be
a web page that is capable of functioning offline, though certain
functions might be unavailable.
At some after content is received, the user agent might want to
establish a connection to the server and continue use. True
continuity of use could depend on state established during the period
that the user agent did not contact the server.
This document proposes a design whereby content can be ascribed an
identity that is based solely on that content. Together with a means
of transferring control over state established by one origin to
another, this allows content to be delivered offline and used with
the ability to transition to a full online interaction with a web
server.
Content-based origins are proposed as an alternative to signed
exchanges [SXG], which ascribe an HTTPS origin to content through the
use of signatures. Signed exchanges depends on finding a way to
modify the core concept of web origins that allows for object-based
authority. Signed exchanges avoid any problems arising from transfer
of state between origins. However, a fundamental change to the way
in which authority is determined requires the use of a number of
safeguards. These safeguards contain both technical mechanisms and
usage constraints. These constraints could be operationally
challenging to meet, but violating them could have consequences for
security.
Thomson Expires 10 September 2020 [Page 3]
Internet-Draft Content-Based Origins March 2020
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the term "user agent" consistent with the usage in
both [HTTP] and [HTML]. Colloquially, "user agent" is a web browser.
3. Overview and Comparisons
This section provides an overview of how content-based origins might
be used and compares that to designs based on signed exchanges.
The most interesting scenario involves the transition from an state
where the target origin has not been contacted (that is, the user
agent is either offline or effectively so), to one where the user
agent contacts the target origin (the user agent is online).
3.1. Offline-to-Online Transition for Content-Based Origins
For a content-based origin, content is loaded from a bundle. After
loading the bundle, the browser treats content in the bundle as
existing in an origin unique to the content of the bundle; see
Section 4.
If the bundle contains a transfer target URL (see Section 5.3), the
browser then attempts to load that resource, providing an indication
to the target origin that a transfer from the content-based origin is
possible. If the origin accepts the transfer of state, state is
transferred from the content-based origin to the target origin. This
sequence is shown in Figure 1.
Thomson Expires 10 September 2020 [Page 4]
Internet-Draft Content-Based Origins March 2020
+---------------+
| Load Bundle |
+---------------+
|
v
+---------------+ +---------+
Aborted +-----| Content-Based |=======| State |
Transfer +---->| Origin | +---------+
+---------------+ :
| State Transfer :
| IFF Origin Accepts :
v v
+---------------+ +---------+
| Online at |=======| State |
| Target Origin | +---------+
+---------------+
Figure 1: State Transfer for Content-Based Origins
Failure to connect to the target origin - such as when the browser
has no active Internet connection - causes the redirect to be
aborted. The browser continues to display the bundle content.
If the origin does not accept the transfer, the browser shows content
from the target origin and any state from the bundle is destroyed.
3.2. Offline-to-Online Transition for Signed Exchanges
With [LOADING] and [SXG], content is loaded from a signed bundle.
After loading the bundle, if the signature is considered valid, the
browser stores bundled content in a cache that is specific to the
target origin. The browser then redirects to the request (or target)
URL from the bundle. The browser uses content from the bundle in
place of fetching from the origin. This is illustrated in Figure 2.
Thomson Expires 10 September 2020 [Page 5]
Internet-Draft Content-Based Origins March 2020
+-----------------+
| Load Bundle |
+-----------------+
| ..If signature is trusted...
v : :
+-----------------+ : +-----------------+ :
| Check Signature +------>| Store Exchanges | :
+-----------------+ : +-----------------+ :
Redirect | : :
v : :
+-----------------+ : +-----------------+ :
| Online at |<------| Use Exchanges | :
| Request URL | : +-----------------+ :
+-----------------+ :...........................
Figure 2: Content Use with Signed Exchanges
Having signed content from the bundle allows use of that content
prior to connecting to the origin. Importantly, it allows
attribution of any operations to that origin. Optimizations that
otherwise might not be possible are enabled because resources from
the bundle can be treated as if they were loaded from the target
origin, but the browser does not need to make a request to the
origin.
Critically, if the browser is fully offline, it can decide to operate
with the bundle without having to connect to the origin. If the
bundled content is signed and trusted, the application to operate
offline. Any actions performed act on state for the target origin.
Note: While Service Workers [SERVICE-WORKERS] can offer a similar
experience, they require that the browser be online initially to
load the service worker script. This design requires no prior
interaction with the target origin.
Relative to content-based origins, the use of signatures avoids the
need to connect to the target origin and confirm knowledge of the
content. For cases where the transition to online status is intended
to be immediate, signed exchanges allow a redirect to happen without
any requests being made. A signed exchange will therefore display
content that is attributed to the target origin faster.
Failure to validate a signature causes a redirect to an online
location. If the client is offline, that origin will be
inaccessible. If the client is online, none of the optimizations
afforded by the bundle are available and this appears to be a normal
redirection.
Thomson Expires 10 September 2020 [Page 6]
Internet-Draft Content-Based Origins March 2020
[[Note that it is unclear whether a browser might be able to fall
back to treating a signed bundle as unsigned if the signature is
bad.]]
3.3. Comparison with Signed Exchanges
Signed exchanges attempt to address the problem of attributing
content to an origin. In effect, they add an object-based security
model to the existing channel-based model used on the web.
Signatures over bundles (or parts thereof) are used by an origin to
attest to the contents of a bundle.
Having two security models operate in the same space potentially
creates an exposure to the worst properties of each model. To reduce
the chances that the drawbacks of the newly-added object-based model
affect existing channel-based usages, signed exchanges include a
number of hardening measures. In addition to signatures, there are
required modifications to certificates, constraints on validity
periods, and a range of limitations on the types of content that can
be signed.
In comparison, content-based origins do not require signatures.
Questions of validity only apply at the point that a state transfer
is attempted. However, this has drawbacks also. Content is not
attributed to origins and state is not available to an online origin
until a transfer is complete. This avoids the complexity inherent to
merging two different security models, but the process of state
transfer could be quite complicated in practice.
In terms of usability, the identity attributed to content from a
content-based origin is opaque and not particularly relatable.
Though state might eventually be adopted by some origin,
communicating the true status of content could be challenging.
Finally, content-based origins aren't prevented from interacting with
HTTP origins, which could lead to surprising outcomes if existing
code is poorly unprepared for this possibility.
3.4. Comparison with Unsigned Bundles
Unsigned bundles [UNSIGNED] proposes a model whereby bundles served
by a given origin could be declared to be part of that origin and
trusted. Unsigned bundles would otherwise be considered untrusted
and would be isolated in some fashion. This is similar to the way in
which a content-based origin might be transferred to a target origin.
That proposal divides bundles into trusted and untrusted bundles.
Trusted bundles would be able to access state from the origin that
served them.
Thomson Expires 10 September 2020 [Page 7]
Internet-Draft Content-Based Origins March 2020
In comparison, content-based origins would always be used for bundles
and the distinction between trusted and untrusted is unnecessary.
Content from the bundle would be usable to a target origin that
accepts a state transfer.
4. Content-Based Origin Definition
A content-based origin ascribes an identity to content based on the
content itself. For instance, a web bundle [BUNDLE] is assigned a
URI based on its content alone.
The sequence of bytes that comprises the content or bundled content
is hashed using a hash function that is strongly resistant to
collision and pre-image attack, such as SHA-256 [SHA-2]. The
resulting hash is encoded using the Base 64 encoding with an URL and
filename safe alphabet [BASE64].
This can be formed into the ASCII or Unicode serialization of an
origin based on the Named Information URI scheme [NI]. This URI is
formed from the string "ni:///", the identifier for the hash
algorithm (see Section 9.4 of [NI]); a semi-colon (";"), and the
base64url encoding of the hash function output. Though this uses the
ni URL form, the authority and query strings are omitted from this
serialization.
For instance, the origin of content comprising the single ASCII
character 'a' is represented as "ni:///sha-
256;ypeBEsobvcr6wjGzmiPcTaeG7_gUfE5yuYB3ha_uSLs".
In tuple form, the origin is comprised of the scheme ("ni") and a
host equal to the concatenation of hash algorithm identifier, semi-
colon, and base64url-encoded hash function output. The port number
is always absent for an origin in this form.
Design Note: This design currently assumes that there won't be a
hash-based URI scheme developed for bundles. It would be vastly
preferable to have a URI scheme for bundled content. It would
then be possible to reference content in a bundle from outside the
bundle, and internal references could be canonicalized.
Importantly, state transfer could also be initiated _toward_
another bundle. That could be used to upgrade bundles and other
nice features.
This definition of origin for named information ("ni://") URIs
extends the definition of origin in Section 4 of [ORIGIN].
Thomson Expires 10 September 2020 [Page 8]
Internet-Draft Content-Based Origins March 2020
4.1. Content Type Malleability
The hash used to generate this origin does not include any indication
of content type or the source of information. If it were possible
for the same content to be interpreted as valid instances of multiple
different content types, that might be exploited by an attacker.
A user agent SHOULD enact a policy of only attributing a content-
based origin to content that is unambiguously interpreted in a single
form. If it were possible for content to be interpreted as valid for
multiple content types and those could be attributed to the same
content-based origin, that might be exploited by an attacker. A
sample policy might only allow web bundles and HTML files to be
assigned a content-based origin; as the first bytes of these formats
are unambiguously different, this ensures that the same content to be
interpreted as valid for both content types.
4.2. Hash Agility
This design depends to some extent on the hash algorithm remaining
constant during the time that the content-based origin is used. A
change in hash algorithm changes the identity of the resource.
It is possible to transfer state from a content-based origin derived
using one hash algorithm to another without affecting the content of
the origin itself. It is not often that content depends on knowing
its own identity. However, the identity of the origin might be made
visible to other origins. For instance, the window.postMessage API
[HTML] allows content to target a specific origin for sending
messages and to identify the source origin of incoming messages.
For the purposes of determining equality, user agents might consider
hashes of the same content with different hash algorithms to be
equal. For instance, a user agent might consider "sha-
256:ypeBEsobvcr6wjGzmiPcTaeG7_gUfE5yuYB3ha_uSLs" to be equal to "sha-
384;VKWbnyKwuAiA2EJ-VIt8I6vYc0huHwNdzpzWl-
hRdQM8qojm1XvDXvrgta_TFF8x". This requires that this equivalence is
known to the user agent.
Of the hash algorithms defined in [NI], only "sha-256" is permitted
for use with content-based origins. This usage has no need for a
truncated hash as the value does not usually need to be manually
entered. Furthermore, the use of multiple hash algorithms introduces
complexity.
Thomson Expires 10 September 2020 [Page 9]
Internet-Draft Content-Based Origins March 2020
5. Transfer to HTTPS Origin
In order to transfer state to a target origin, the server for that
origin needs to be contacted. Initiating transfer likely requires
that an API be defined for use by the content of the bundle.
Transfer might be automatically initiated when navigating to a URL
from a bundle; see Section 5.5.
A transfer is only possible where a transfer target URL is known for
content; see Section 5.3.
After a state transfer is initiated, the user agent fetches the
transfer target URL. The source content is hashed twice; once as
described in Section 4; then the resulting value is hashed again.
The twice-hashed value is encoded into a Sec-Content-Origin header
field and added to the request for the transfer target URL. If a
Sec-Content-Origin header field in the response contains the hash of
the content (that is, the pre-image of the value in the request),
that indicates that the server is both willing to receive the
transfer and that the server knows the content.
The value of the Sec-Content-Origin header field is expressed as a
structured header [SH] dictionary with keys being the hash algorithm
identifier (from [NI]) and byte sequence values of the hash.
Multiple values can be provided with different hash algorithm
identifiers. The values from the response correspond to the values
in the request with the same hash algorithm identifier. For the
transfer to be successful, clients MUST validate that at least one
value in the response hashes to the corresponding value in the
request; clients SHOULD validate all provided values. If the content
does not hash to the any provided value, the transfer is
unsuccessful.
Note: The response to a state transfer can be served from cache.
5.1. Successful Transfer
If the transfer is successful, state associated with the content-
based origin will be transferred to the target origin. The user
agent MAY either remember the identity of the content-based origin
and consider any content-based origin to be equal to the transferred
origin.
For example, assuming that a single 'a' character is valid content,
then the client would include the following in a request (line breaks
are added to examples for formatting reasons):
Thomson Expires 10 September 2020 [Page 10]
Internet-Draft Content-Based Origins March 2020
Sec-Content-Origin:
sha-256=:v106/7c+/S7Gw2rTES3ZM+/tY8Thy//PqI4nWcFE8tg=:
A successful state transfer would occur if the response from the
server included:
Sec-Content-Origin:
sha-256=:ypeBEsobvcr6wjGzmiPcTaeG7/gUfE5yuYB3ha/uSLs=:
A user agent that automatically follows redirections (3xx status
codes) MUST allow the server to redirect to a resource that provides
the response. Redirection can change the origin that ultimately
accepts the transfer. Any redirection to an origin that is not
strongly authenticated MUST cause the transfer to fail.
After a successful transfer, the user agent MAY treat the content-
based origin as an alias for the origin to which state was
transferred. This aliasing might be particularly useful in
addressing hash agility; see Section 4.2.
5.2. Unsuccessful Transfer
A transfer can be unsuccessful in two ways. If the target origin
cannot be contacted successfully, the content-based origin continues
to exist. Any API might indicate that the attempt failed. Failure
to transfer state is expected when the user agent is offline. After
failing to contact the target origin, a transfer can be attempted at
a later time. This causes navigation to fail and the user agent MAY
display a URL from the content-based origin.
[[TODO: Again, this requires that we define a means of identification
for content inside bundles.]]
A valid, final HTTP response that indicates anything other than a
server error (that is, 5xx status codes) or lack of authority (the
421 status code [HTTP2]) without including the hash pre-image in the
response MUST be treated as a failed migration. After a failed
migration, information about the target origin SHOULD be removed from
interfaces related to the content-based origin, except for diagnostic
purposes. The content-based origin MAY continue to exist but further
attempts to transfer state MUST immediately fail.
After a valid HTTP response, the user agent navigates to the transfer
target URL or any resource that was included in any redirections.
Any valid HTTP response, successful or not, MUST cause data
associated with the content-based origin to be cleared as though
clear-site-data were invoked [CLEAR-DATA].
Thomson Expires 10 September 2020 [Page 11]
Internet-Draft Content-Based Origins March 2020
5.3. Transfer Target
To enable transfer, content MUST include an attribute that indicates
the transfer target URL. If a bundle could contain multiple
potential entry points, each entry point for the bundle would
separately specify a different transfer target URL.
[[Intuitively, it seems prudent to limit transfer target URLs in the
same bundle to the same origin, but I don't have a concrete reason
for doing so right now.]]
A transfer target URL does not need to be specified if the intent is
to never support the ability to transfer to an online state.
The origin of the transfer target URL is the target origin. Only the
target origin can be the target of a state transfer. After a
successful transfer, the user agent loads the transfer target URL.
Note: Including the transfer target URL in content means that the
content hash is dependent on its value. This ensures that
different content-based origins are produced if different transfer
target URLs are used. Two different origins cannot share state.
A commitment in this form could allow user agents to present the
target origin in interfaces. While no strong assurances can be made
about the attribution of content to this origin, this might make it
easier to generate user interfaces.
Different content types might provide a way of encoding the transfer
target URL. The URL could be provided external to the content, but
this requires some unspecified means of ensuring that the content-
based origin depends on the value of the URL; this document only
supports content that can encode the transfer target URL.
5.4. State Transfer
Only limited state information can be transferred between origins.
This is limited to those items that are identified here, or those
that are added in later extensions. This document describes how
content (Section 5.4.1), stored data Section 5.4.2), and permissions
Section 5.4.3 are transferred.
Upon successful completion of transfer, if loading the transfer
target resource produces an HTML document, an event is delivered to
content of that resource that describes what information was
transferred.
Thomson Expires 10 September 2020 [Page 12]
Internet-Draft Content-Based Origins March 2020
A user agent MAY request user permission to transfer some state.
This might be conditioned on what state is being transferred. For
instance, a user agent might prompt before transferring permissions
[PERMISSIONS]; see Section 5.4.3.
5.4.1. Transfer of Content
How content that is delivered in the bundle is used by the target
origin is probably the most important aspect of any design in this
space. This document proposes that all content in the bundle is
adopted by the origin after a transfer completes.
This design means that bundles need a way to describe how all their
resources map to URLs in the target origin. If it is possible for
bundles to contain content from multiple origins, content from other
origins won't be accessible after transfer without first making a
request to the other origin.
Content loaded from a bundle MUST NOT be made available for use by
origins other than the target origin. For example, if the bundle
includes a script that maps to a URL on the target origin and a site
at another origin loads that script, then the user agent fetches the
script. The user agent MAY use a conditional request with If-None-
Digest [IF-DIGEST] and the Digest header field [DIGEST] to reduce the
overhead of these requests at its discretion, noting that this might
introduce observable timing signals.
Restricting content to use by the target origin avoids the negative
effects described in [SRI-ADDRESSABLE]. The target origin is
required to demonstrate knowledge of the contents of the bundle,
which prevents that origin from being poisoned by an attacker. For
origins other than the target origin, content cannot be emplaced
through the use of a bundle.
Alternative methods for transfer of content might require per-
resource confirmation by the origin. That might be loosened so that
resources that use Subresource Integrity [SRI] do not require
confirmation. But that increases the need to provide integrity
attributes at the point that resources are referred to. If content
is fetched programmatically, that might be operationally challenging.
5.4.2. Transfer of Storage
Upon transfer, any indexedDB databases [INDEXEDDB] are transferred to
the target origin. The names of any databases are prefixed with the
origin from which they came. If a database with the same name exists
at the destination, a new name is selected.
Thomson Expires 10 September 2020 [Page 13]
Internet-Draft Content-Based Origins March 2020
The event that indicates transfer will list the databases that were
transferred, their names and any name changes.
5.4.3. Transfer of Permissions
As part of a state transfer, any persistent permissions that a user
granted the content-based origin might be transferred to the target
origin.
Whether any given permission is transferred and what conditions are
attached to the transferral will depend on the policy of the user
agent. It might be considered best to discard permissions and
request each anew as necessary. As transferral is a one-time event,
causing prompts to be reinitiated might not be too much of an
imposition.
5.5. Navigation Transfers
Initiating transfer on navigation enables pre-loading of content from
bundles.
To address this use case, the user agent navigates to a bundle. That
bundle might be served from the site providing the link to ensure
that information about the linking page is not revealed to the target
origin prior to navigation.
Navigating to the bundle causes an immediate load of the content of
the bundle. This assumes that there is either a URL component that
specifies a single entry point for the bundle or that the bundle
itself identifies the entrypoint.
If a transfer target URL is specified for the target resource, the
user agent navigates to that URL. The user agent MUST fetch the
transfer target URL and include a Sec-Content-Origin header field in
the request as described in Section 5. This request MAY also include
the ETag header field from the bundled content.
Using If-None-Digest [IF-DIGEST] allows the resource at the transfer
target URL to return a 304 (Not Modified) status code in response to
a request if the content provided in the bundle known to the server
to be sufficient.
The result is that the state from the bundle is transferred to the
target origin. As the navigation is immediate, no state will have
been created within the bundle so the transfer of state can be
skipped by the browser if navigation from a previously unused
content-based origin is successful. It is possible that the content-
Thomson Expires 10 September 2020 [Page 14]
Internet-Draft Content-Based Origins March 2020
based origin might have previously used, in which case state
transferrance might occur.
5.6. Communication Between Origins
Without knowledge of the content of a resource, or bundle of
resources, a content-based origin will be impossible to guess. This
means that communication is only possible if the frame in which the
content is loaded by the origin attempting communication, or the
content is known to that origin.
6. Security Considerations
This design avoids questions about having to attribute authority to a
static bundle of content. Instead, it creates a new origin type and
enables the transfer of state from one origin to another. The target
origin can decide whether to accept a transfer, thereby avoiding any
questions of poisoning of content. If content is found to be
compromised, an origin can subsequently refuse to accept a transfer
from that content.
Transfer of state to an origin with an "http://" origin is not
possible. This mechanism depends on the target origin being strongly
authenticated.
7. IANA Considerations
[[TODO: Register the Sec-Content-Origin header field. Probably a lot
more.]]
8. References
8.1. Normative References
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[BUNDLE] Yasskin, J., "Bundled HTTP Exchanges", Work in Progress,
Internet-Draft, draft-yasskin-wpack-bundled-exchanges-02,
26 September 2019, <http://www.ietf.org/internet-drafts/
draft-yasskin-wpack-bundled-exchanges-02.txt>.
[HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-07, 7 March 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-httpbis-semantics-07.txt>.
Thomson Expires 10 September 2020 [Page 15]
Internet-Draft Content-Based Origins March 2020
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[NI] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SH] Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
Work in Progress, Internet-Draft, draft-ietf-httpbis-
header-structure-14, 28 January 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
header-structure-14.txt>.
[SXG] Yasskin, J., "Signed HTTP Exchanges", Work in Progress,
Internet-Draft, draft-yasskin-http-origin-signed-
responses-08, 4 November 2019, <http://www.ietf.org/
internet-drafts/draft-yasskin-http-origin-signed-
responses-08.txt>.
8.2. Informative References
[CLEAR-DATA]
West, M., "Clear Site Data", W3C ED, 13 November 2017,
<https://w3c.github.io/webappsec-clear-site-data/>.
[DIGEST] Polli, R. and L. Pardue, "Digest Headers", Work in
Progress, Internet-Draft, draft-ietf-httpbis-digest-
headers-01, 3 November 2019, <http://www.ietf.org/
internet-drafts/draft-ietf-httpbis-digest-headers-01.txt>.
[HTML] WhatWG, ., "HTML", WhatWG Living Standard, 4 March 2020,
<https://html.spec.whatwg.org/>.
Thomson Expires 10 September 2020 [Page 16]
Internet-Draft Content-Based Origins March 2020
[IF-DIGEST]
Thomson, M., "Conditional HTTP Requests Using Digests",
Work in Progress, Internet-Draft, draft-thomson-http-if-
digest-00, 9 March 2020, <https://tools.ietf.org/html/
draft-thomson-http-if-digest-00>.
[INDEXEDDB]
Alabbas, A. and J. Bell, "Indexed Database API 3.0",
W3C ED, 29 February 2020,
<https://w3c.github.io/IndexedDB/>.
[LOADING] Yasskin, J., "Loading Signed Exchanges", 21 February 2020,
<https://wicg.github.io/webpackage/loading.html>.
[PERMISSIONS]
Lamouri, M., Cáceres, M., and J. Yasskin, "Permissions",
W3C ED, 30 October 2019,
<https://w3c.github.io/permissions/>.
[SERVICE-WORKERS]
Russell, A., Song, J., Archibald, J., and M.
Kruisselbrink, "Service Workers 1", W3C ED, 24 February
2020, <https://w3c.github.io/ServiceWorker/v1/>.
[SHA-2] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
"Subresource Integrity", W3C ED, 4 January 2020,
<https://w3c.github.io/webappsec-subresource-integrity/>.
[SRI-ADDRESSABLE]
Hill, B., "Subresource Integrity Addressable Caching", 15
October 2016, <https://hillbrad.github.io/sri-addressable-
caching/sri-addressable-caching.html>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[UNSIGNED] Yasskin, J., "Navigation to Unsigned Web Bundles", 20
February 2020,
<https://github.com/WICG/webpackage/blob/master/
explainers/navigation-to-unsigned-bundles.md>.
Thomson Expires 10 September 2020 [Page 17]
Internet-Draft Content-Based Origins March 2020
Acknowledgments
This work is hardly original, nor is it an individual effort.
[[TODO: acknowledge.]]
Author's Address
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Thomson Expires 10 September 2020 [Page 18]
