idnits 2.17.1 draft-thomson-wpack-content-origin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6454, but the abstract doesn't seem to directly say this. It does mention RFC6454 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-yasskin-wpack-bundled-exchanges-02 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-07 -- Possible downref: Normative reference to a draft: ref. 'HTTP' ** Obsolete normative reference: RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-14 == Outdated reference: A later version (-09) exists of draft-yasskin-http-origin-signed-responses-08 == Outdated reference: A later version (-13) exists of draft-ietf-httpbis-digest-headers-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 wpack M. Thomson 3 Internet-Draft Mozilla 4 Updates: 6454 (if approved) 9 March 2020 5 Intended status: Standards Track 6 Expires: 10 September 2020 8 Content-Based Origins for the Web 9 draft-thomson-wpack-content-origin-00 11 Abstract 13 Making content available to clients that are unable or unwilling to 14 contact a web origin enables new means of acquiring content. This 15 document describes a method for taking application state accumulated 16 by an offline user agent in relation to a piece of content and making 17 that state available in a fully online context. This enables 18 continuous use of content, starting from a state where the user agent 19 does not contact an origin and ending with 21 This document proposes an update to the definition of Origin in RFC 22 6454. It also proposes changes that would affect HTML, which is 23 outside of the remit of the IETF. 25 Note to Readers 27 Discussion of this document takes place on the WPACK Working Group 28 mailing list (wpack@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/wpack/ 30 (https://mailarchive.ietf.org/arch/browse/wpack/). 32 Source for this draft and an issue tracker can be found at 33 https://github.com/martinthomson/wpack-content 34 (https://github.com/martinthomson/wpack-content). 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 10 September 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 71 3. Overview and Comparisons . . . . . . . . . . . . . . . . . . 4 72 3.1. Offline-to-Online Transition for Content-Based Origins . 4 73 3.2. Offline-to-Online Transition for Signed Exchanges . . . . 5 74 3.3. Comparison with Signed Exchanges . . . . . . . . . . . . 7 75 3.4. Comparison with Unsigned Bundles . . . . . . . . . . . . 7 76 4. Content-Based Origin Definition . . . . . . . . . . . . . . . 8 77 4.1. Content Type Malleability . . . . . . . . . . . . . . . . 9 78 4.2. Hash Agility . . . . . . . . . . . . . . . . . . . . . . 9 79 5. Transfer to HTTPS Origin . . . . . . . . . . . . . . . . . . 10 80 5.1. Successful Transfer . . . . . . . . . . . . . . . . . . . 10 81 5.2. Unsuccessful Transfer . . . . . . . . . . . . . . . . . . 11 82 5.3. Transfer Target . . . . . . . . . . . . . . . . . . . . . 12 83 5.4. State Transfer . . . . . . . . . . . . . . . . . . . . . 12 84 5.4.1. Transfer of Content . . . . . . . . . . . . . . . . . 13 85 5.4.2. Transfer of Storage . . . . . . . . . . . . . . . . . 13 86 5.4.3. Transfer of Permissions . . . . . . . . . . . . . . . 14 87 5.5. Navigation Transfers . . . . . . . . . . . . . . . . . . 14 88 5.6. Communication Between Origins . . . . . . . . . . . . . . 15 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 8.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 The web relies on the concept of origins [ORIGIN] as the primary 100 means of identification for resources. A strongly authenticated 101 HTTPS origin is the basis for many security decisions. However, 102 establishing this identity relies on having an active TLS [TLS] 103 connection to a server that is considered authoritative for the 104 origin; see Section 11 of [HTTP]. 106 A user agent that is offline when content is received cannot 107 establish this authority. Similarly, a user agent might be unwilling 108 to contact a server at the time that content is received. One reason 109 for not contacting a server might be to avoid leaking information 110 about the context in which content was referenced. In either case, 111 content cannot be attributed to the origin at the time it is 112 received. 114 In operation, content might be delivered by any means other than a 115 TLS connection to the intended server. Then there might be a period 116 during which the content is used. For instance, the content might be 117 a web page that is capable of functioning offline, though certain 118 functions might be unavailable. 120 At some after content is received, the user agent might want to 121 establish a connection to the server and continue use. True 122 continuity of use could depend on state established during the period 123 that the user agent did not contact the server. 125 This document proposes a design whereby content can be ascribed an 126 identity that is based solely on that content. Together with a means 127 of transferring control over state established by one origin to 128 another, this allows content to be delivered offline and used with 129 the ability to transition to a full online interaction with a web 130 server. 132 Content-based origins are proposed as an alternative to signed 133 exchanges [SXG], which ascribe an HTTPS origin to content through the 134 use of signatures. Signed exchanges depends on finding a way to 135 modify the core concept of web origins that allows for object-based 136 authority. Signed exchanges avoid any problems arising from transfer 137 of state between origins. However, a fundamental change to the way 138 in which authority is determined requires the use of a number of 139 safeguards. These safeguards contain both technical mechanisms and 140 usage constraints. These constraints could be operationally 141 challenging to meet, but violating them could have consequences for 142 security. 144 2. Conventions and Definitions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 This document uses the term "user agent" consistent with the usage in 153 both [HTTP] and [HTML]. Colloquially, "user agent" is a web browser. 155 3. Overview and Comparisons 157 This section provides an overview of how content-based origins might 158 be used and compares that to designs based on signed exchanges. 160 The most interesting scenario involves the transition from an state 161 where the target origin has not been contacted (that is, the user 162 agent is either offline or effectively so), to one where the user 163 agent contacts the target origin (the user agent is online). 165 3.1. Offline-to-Online Transition for Content-Based Origins 167 For a content-based origin, content is loaded from a bundle. After 168 loading the bundle, the browser treats content in the bundle as 169 existing in an origin unique to the content of the bundle; see 170 Section 4. 172 If the bundle contains a transfer target URL (see Section 5.3), the 173 browser then attempts to load that resource, providing an indication 174 to the target origin that a transfer from the content-based origin is 175 possible. If the origin accepts the transfer of state, state is 176 transferred from the content-based origin to the target origin. This 177 sequence is shown in Figure 1. 179 +---------------+ 180 | Load Bundle | 181 +---------------+ 182 | 183 v 184 +---------------+ +---------+ 185 Aborted +-----| Content-Based |=======| State | 186 Transfer +---->| Origin | +---------+ 187 +---------------+ : 188 | State Transfer : 189 | IFF Origin Accepts : 190 v v 191 +---------------+ +---------+ 192 | Online at |=======| State | 193 | Target Origin | +---------+ 194 +---------------+ 196 Figure 1: State Transfer for Content-Based Origins 198 Failure to connect to the target origin - such as when the browser 199 has no active Internet connection - causes the redirect to be 200 aborted. The browser continues to display the bundle content. 202 If the origin does not accept the transfer, the browser shows content 203 from the target origin and any state from the bundle is destroyed. 205 3.2. Offline-to-Online Transition for Signed Exchanges 207 With [LOADING] and [SXG], content is loaded from a signed bundle. 208 After loading the bundle, if the signature is considered valid, the 209 browser stores bundled content in a cache that is specific to the 210 target origin. The browser then redirects to the request (or target) 211 URL from the bundle. The browser uses content from the bundle in 212 place of fetching from the origin. This is illustrated in Figure 2. 214 +-----------------+ 215 | Load Bundle | 216 +-----------------+ 217 | ..If signature is trusted... 218 v : : 219 +-----------------+ : +-----------------+ : 220 | Check Signature +------>| Store Exchanges | : 221 +-----------------+ : +-----------------+ : 222 Redirect | : : 223 v : : 224 +-----------------+ : +-----------------+ : 225 | Online at |<------| Use Exchanges | : 226 | Request URL | : +-----------------+ : 227 +-----------------+ :........................... 229 Figure 2: Content Use with Signed Exchanges 231 Having signed content from the bundle allows use of that content 232 prior to connecting to the origin. Importantly, it allows 233 attribution of any operations to that origin. Optimizations that 234 otherwise might not be possible are enabled because resources from 235 the bundle can be treated as if they were loaded from the target 236 origin, but the browser does not need to make a request to the 237 origin. 239 Critically, if the browser is fully offline, it can decide to operate 240 with the bundle without having to connect to the origin. If the 241 bundled content is signed and trusted, the application to operate 242 offline. Any actions performed act on state for the target origin. 244 Note: While Service Workers [SERVICE-WORKERS] can offer a similar 245 experience, they require that the browser be online initially to 246 load the service worker script. This design requires no prior 247 interaction with the target origin. 249 Relative to content-based origins, the use of signatures avoids the 250 need to connect to the target origin and confirm knowledge of the 251 content. For cases where the transition to online status is intended 252 to be immediate, signed exchanges allow a redirect to happen without 253 any requests being made. A signed exchange will therefore display 254 content that is attributed to the target origin faster. 256 Failure to validate a signature causes a redirect to an online 257 location. If the client is offline, that origin will be 258 inaccessible. If the client is online, none of the optimizations 259 afforded by the bundle are available and this appears to be a normal 260 redirection. 262 [[Note that it is unclear whether a browser might be able to fall 263 back to treating a signed bundle as unsigned if the signature is 264 bad.]] 266 3.3. Comparison with Signed Exchanges 268 Signed exchanges attempt to address the problem of attributing 269 content to an origin. In effect, they add an object-based security 270 model to the existing channel-based model used on the web. 271 Signatures over bundles (or parts thereof) are used by an origin to 272 attest to the contents of a bundle. 274 Having two security models operate in the same space potentially 275 creates an exposure to the worst properties of each model. To reduce 276 the chances that the drawbacks of the newly-added object-based model 277 affect existing channel-based usages, signed exchanges include a 278 number of hardening measures. In addition to signatures, there are 279 required modifications to certificates, constraints on validity 280 periods, and a range of limitations on the types of content that can 281 be signed. 283 In comparison, content-based origins do not require signatures. 284 Questions of validity only apply at the point that a state transfer 285 is attempted. However, this has drawbacks also. Content is not 286 attributed to origins and state is not available to an online origin 287 until a transfer is complete. This avoids the complexity inherent to 288 merging two different security models, but the process of state 289 transfer could be quite complicated in practice. 291 In terms of usability, the identity attributed to content from a 292 content-based origin is opaque and not particularly relatable. 293 Though state might eventually be adopted by some origin, 294 communicating the true status of content could be challenging. 295 Finally, content-based origins aren't prevented from interacting with 296 HTTP origins, which could lead to surprising outcomes if existing 297 code is poorly unprepared for this possibility. 299 3.4. Comparison with Unsigned Bundles 301 Unsigned bundles [UNSIGNED] proposes a model whereby bundles served 302 by a given origin could be declared to be part of that origin and 303 trusted. Unsigned bundles would otherwise be considered untrusted 304 and would be isolated in some fashion. This is similar to the way in 305 which a content-based origin might be transferred to a target origin. 307 That proposal divides bundles into trusted and untrusted bundles. 308 Trusted bundles would be able to access state from the origin that 309 served them. 311 In comparison, content-based origins would always be used for bundles 312 and the distinction between trusted and untrusted is unnecessary. 313 Content from the bundle would be usable to a target origin that 314 accepts a state transfer. 316 4. Content-Based Origin Definition 318 A content-based origin ascribes an identity to content based on the 319 content itself. For instance, a web bundle [BUNDLE] is assigned a 320 URI based on its content alone. 322 The sequence of bytes that comprises the content or bundled content 323 is hashed using a hash function that is strongly resistant to 324 collision and pre-image attack, such as SHA-256 [SHA-2]. The 325 resulting hash is encoded using the Base 64 encoding with an URL and 326 filename safe alphabet [BASE64]. 328 This can be formed into the ASCII or Unicode serialization of an 329 origin based on the Named Information URI scheme [NI]. This URI is 330 formed from the string "ni:///", the identifier for the hash 331 algorithm (see Section 9.4 of [NI]); a semi-colon (";"), and the 332 base64url encoding of the hash function output. Though this uses the 333 ni URL form, the authority and query strings are omitted from this 334 serialization. 336 For instance, the origin of content comprising the single ASCII 337 character 'a' is represented as "ni:///sha- 338 256;ypeBEsobvcr6wjGzmiPcTaeG7_gUfE5yuYB3ha_uSLs". 340 In tuple form, the origin is comprised of the scheme ("ni") and a 341 host equal to the concatenation of hash algorithm identifier, semi- 342 colon, and base64url-encoded hash function output. The port number 343 is always absent for an origin in this form. 345 Design Note: This design currently assumes that there won't be a 346 hash-based URI scheme developed for bundles. It would be vastly 347 preferable to have a URI scheme for bundled content. It would 348 then be possible to reference content in a bundle from outside the 349 bundle, and internal references could be canonicalized. 350 Importantly, state transfer could also be initiated _toward_ 351 another bundle. That could be used to upgrade bundles and other 352 nice features. 354 This definition of origin for named information ("ni://") URIs 355 extends the definition of origin in Section 4 of [ORIGIN]. 357 4.1. Content Type Malleability 359 The hash used to generate this origin does not include any indication 360 of content type or the source of information. If it were possible 361 for the same content to be interpreted as valid instances of multiple 362 different content types, that might be exploited by an attacker. 364 A user agent SHOULD enact a policy of only attributing a content- 365 based origin to content that is unambiguously interpreted in a single 366 form. If it were possible for content to be interpreted as valid for 367 multiple content types and those could be attributed to the same 368 content-based origin, that might be exploited by an attacker. A 369 sample policy might only allow web bundles and HTML files to be 370 assigned a content-based origin; as the first bytes of these formats 371 are unambiguously different, this ensures that the same content to be 372 interpreted as valid for both content types. 374 4.2. Hash Agility 376 This design depends to some extent on the hash algorithm remaining 377 constant during the time that the content-based origin is used. A 378 change in hash algorithm changes the identity of the resource. 380 It is possible to transfer state from a content-based origin derived 381 using one hash algorithm to another without affecting the content of 382 the origin itself. It is not often that content depends on knowing 383 its own identity. However, the identity of the origin might be made 384 visible to other origins. For instance, the window.postMessage API 385 [HTML] allows content to target a specific origin for sending 386 messages and to identify the source origin of incoming messages. 388 For the purposes of determining equality, user agents might consider 389 hashes of the same content with different hash algorithms to be 390 equal. For instance, a user agent might consider "sha- 391 256:ypeBEsobvcr6wjGzmiPcTaeG7_gUfE5yuYB3ha_uSLs" to be equal to "sha- 392 384;VKWbnyKwuAiA2EJ-VIt8I6vYc0huHwNdzpzWl- 393 hRdQM8qojm1XvDXvrgta_TFF8x". This requires that this equivalence is 394 known to the user agent. 396 Of the hash algorithms defined in [NI], only "sha-256" is permitted 397 for use with content-based origins. This usage has no need for a 398 truncated hash as the value does not usually need to be manually 399 entered. Furthermore, the use of multiple hash algorithms introduces 400 complexity. 402 5. Transfer to HTTPS Origin 404 In order to transfer state to a target origin, the server for that 405 origin needs to be contacted. Initiating transfer likely requires 406 that an API be defined for use by the content of the bundle. 407 Transfer might be automatically initiated when navigating to a URL 408 from a bundle; see Section 5.5. 410 A transfer is only possible where a transfer target URL is known for 411 content; see Section 5.3. 413 After a state transfer is initiated, the user agent fetches the 414 transfer target URL. The source content is hashed twice; once as 415 described in Section 4; then the resulting value is hashed again. 416 The twice-hashed value is encoded into a Sec-Content-Origin header 417 field and added to the request for the transfer target URL. If a 418 Sec-Content-Origin header field in the response contains the hash of 419 the content (that is, the pre-image of the value in the request), 420 that indicates that the server is both willing to receive the 421 transfer and that the server knows the content. 423 The value of the Sec-Content-Origin header field is expressed as a 424 structured header [SH] dictionary with keys being the hash algorithm 425 identifier (from [NI]) and byte sequence values of the hash. 427 Multiple values can be provided with different hash algorithm 428 identifiers. The values from the response correspond to the values 429 in the request with the same hash algorithm identifier. For the 430 transfer to be successful, clients MUST validate that at least one 431 value in the response hashes to the corresponding value in the 432 request; clients SHOULD validate all provided values. If the content 433 does not hash to the any provided value, the transfer is 434 unsuccessful. 436 Note: The response to a state transfer can be served from cache. 438 5.1. Successful Transfer 440 If the transfer is successful, state associated with the content- 441 based origin will be transferred to the target origin. The user 442 agent MAY either remember the identity of the content-based origin 443 and consider any content-based origin to be equal to the transferred 444 origin. 446 For example, assuming that a single 'a' character is valid content, 447 then the client would include the following in a request (line breaks 448 are added to examples for formatting reasons): 450 Sec-Content-Origin: 451 sha-256=:v106/7c+/S7Gw2rTES3ZM+/tY8Thy//PqI4nWcFE8tg=: 453 A successful state transfer would occur if the response from the 454 server included: 456 Sec-Content-Origin: 457 sha-256=:ypeBEsobvcr6wjGzmiPcTaeG7/gUfE5yuYB3ha/uSLs=: 459 A user agent that automatically follows redirections (3xx status 460 codes) MUST allow the server to redirect to a resource that provides 461 the response. Redirection can change the origin that ultimately 462 accepts the transfer. Any redirection to an origin that is not 463 strongly authenticated MUST cause the transfer to fail. 465 After a successful transfer, the user agent MAY treat the content- 466 based origin as an alias for the origin to which state was 467 transferred. This aliasing might be particularly useful in 468 addressing hash agility; see Section 4.2. 470 5.2. Unsuccessful Transfer 472 A transfer can be unsuccessful in two ways. If the target origin 473 cannot be contacted successfully, the content-based origin continues 474 to exist. Any API might indicate that the attempt failed. Failure 475 to transfer state is expected when the user agent is offline. After 476 failing to contact the target origin, a transfer can be attempted at 477 a later time. This causes navigation to fail and the user agent MAY 478 display a URL from the content-based origin. 480 [[TODO: Again, this requires that we define a means of identification 481 for content inside bundles.]] 483 A valid, final HTTP response that indicates anything other than a 484 server error (that is, 5xx status codes) or lack of authority (the 485 421 status code [HTTP2]) without including the hash pre-image in the 486 response MUST be treated as a failed migration. After a failed 487 migration, information about the target origin SHOULD be removed from 488 interfaces related to the content-based origin, except for diagnostic 489 purposes. The content-based origin MAY continue to exist but further 490 attempts to transfer state MUST immediately fail. 492 After a valid HTTP response, the user agent navigates to the transfer 493 target URL or any resource that was included in any redirections. 495 Any valid HTTP response, successful or not, MUST cause data 496 associated with the content-based origin to be cleared as though 497 clear-site-data were invoked [CLEAR-DATA]. 499 5.3. Transfer Target 501 To enable transfer, content MUST include an attribute that indicates 502 the transfer target URL. If a bundle could contain multiple 503 potential entry points, each entry point for the bundle would 504 separately specify a different transfer target URL. 506 [[Intuitively, it seems prudent to limit transfer target URLs in the 507 same bundle to the same origin, but I don't have a concrete reason 508 for doing so right now.]] 510 A transfer target URL does not need to be specified if the intent is 511 to never support the ability to transfer to an online state. 513 The origin of the transfer target URL is the target origin. Only the 514 target origin can be the target of a state transfer. After a 515 successful transfer, the user agent loads the transfer target URL. 517 Note: Including the transfer target URL in content means that the 518 content hash is dependent on its value. This ensures that 519 different content-based origins are produced if different transfer 520 target URLs are used. Two different origins cannot share state. 522 A commitment in this form could allow user agents to present the 523 target origin in interfaces. While no strong assurances can be made 524 about the attribution of content to this origin, this might make it 525 easier to generate user interfaces. 527 Different content types might provide a way of encoding the transfer 528 target URL. The URL could be provided external to the content, but 529 this requires some unspecified means of ensuring that the content- 530 based origin depends on the value of the URL; this document only 531 supports content that can encode the transfer target URL. 533 5.4. State Transfer 535 Only limited state information can be transferred between origins. 536 This is limited to those items that are identified here, or those 537 that are added in later extensions. This document describes how 538 content (Section 5.4.1), stored data Section 5.4.2), and permissions 539 Section 5.4.3 are transferred. 541 Upon successful completion of transfer, if loading the transfer 542 target resource produces an HTML document, an event is delivered to 543 content of that resource that describes what information was 544 transferred. 546 A user agent MAY request user permission to transfer some state. 547 This might be conditioned on what state is being transferred. For 548 instance, a user agent might prompt before transferring permissions 549 [PERMISSIONS]; see Section 5.4.3. 551 5.4.1. Transfer of Content 553 How content that is delivered in the bundle is used by the target 554 origin is probably the most important aspect of any design in this 555 space. This document proposes that all content in the bundle is 556 adopted by the origin after a transfer completes. 558 This design means that bundles need a way to describe how all their 559 resources map to URLs in the target origin. If it is possible for 560 bundles to contain content from multiple origins, content from other 561 origins won't be accessible after transfer without first making a 562 request to the other origin. 564 Content loaded from a bundle MUST NOT be made available for use by 565 origins other than the target origin. For example, if the bundle 566 includes a script that maps to a URL on the target origin and a site 567 at another origin loads that script, then the user agent fetches the 568 script. The user agent MAY use a conditional request with If-None- 569 Digest [IF-DIGEST] and the Digest header field [DIGEST] to reduce the 570 overhead of these requests at its discretion, noting that this might 571 introduce observable timing signals. 573 Restricting content to use by the target origin avoids the negative 574 effects described in [SRI-ADDRESSABLE]. The target origin is 575 required to demonstrate knowledge of the contents of the bundle, 576 which prevents that origin from being poisoned by an attacker. For 577 origins other than the target origin, content cannot be emplaced 578 through the use of a bundle. 580 Alternative methods for transfer of content might require per- 581 resource confirmation by the origin. That might be loosened so that 582 resources that use Subresource Integrity [SRI] do not require 583 confirmation. But that increases the need to provide integrity 584 attributes at the point that resources are referred to. If content 585 is fetched programmatically, that might be operationally challenging. 587 5.4.2. Transfer of Storage 589 Upon transfer, any indexedDB databases [INDEXEDDB] are transferred to 590 the target origin. The names of any databases are prefixed with the 591 origin from which they came. If a database with the same name exists 592 at the destination, a new name is selected. 594 The event that indicates transfer will list the databases that were 595 transferred, their names and any name changes. 597 5.4.3. Transfer of Permissions 599 As part of a state transfer, any persistent permissions that a user 600 granted the content-based origin might be transferred to the target 601 origin. 603 Whether any given permission is transferred and what conditions are 604 attached to the transferral will depend on the policy of the user 605 agent. It might be considered best to discard permissions and 606 request each anew as necessary. As transferral is a one-time event, 607 causing prompts to be reinitiated might not be too much of an 608 imposition. 610 5.5. Navigation Transfers 612 Initiating transfer on navigation enables pre-loading of content from 613 bundles. 615 To address this use case, the user agent navigates to a bundle. That 616 bundle might be served from the site providing the link to ensure 617 that information about the linking page is not revealed to the target 618 origin prior to navigation. 620 Navigating to the bundle causes an immediate load of the content of 621 the bundle. This assumes that there is either a URL component that 622 specifies a single entry point for the bundle or that the bundle 623 itself identifies the entrypoint. 625 If a transfer target URL is specified for the target resource, the 626 user agent navigates to that URL. The user agent MUST fetch the 627 transfer target URL and include a Sec-Content-Origin header field in 628 the request as described in Section 5. This request MAY also include 629 the ETag header field from the bundled content. 631 Using If-None-Digest [IF-DIGEST] allows the resource at the transfer 632 target URL to return a 304 (Not Modified) status code in response to 633 a request if the content provided in the bundle known to the server 634 to be sufficient. 636 The result is that the state from the bundle is transferred to the 637 target origin. As the navigation is immediate, no state will have 638 been created within the bundle so the transfer of state can be 639 skipped by the browser if navigation from a previously unused 640 content-based origin is successful. It is possible that the content- 641 based origin might have previously used, in which case state 642 transferrance might occur. 644 5.6. Communication Between Origins 646 Without knowledge of the content of a resource, or bundle of 647 resources, a content-based origin will be impossible to guess. This 648 means that communication is only possible if the frame in which the 649 content is loaded by the origin attempting communication, or the 650 content is known to that origin. 652 6. Security Considerations 654 This design avoids questions about having to attribute authority to a 655 static bundle of content. Instead, it creates a new origin type and 656 enables the transfer of state from one origin to another. The target 657 origin can decide whether to accept a transfer, thereby avoiding any 658 questions of poisoning of content. If content is found to be 659 compromised, an origin can subsequently refuse to accept a transfer 660 from that content. 662 Transfer of state to an origin with an "http://" origin is not 663 possible. This mechanism depends on the target origin being strongly 664 authenticated. 666 7. IANA Considerations 668 [[TODO: Register the Sec-Content-Origin header field. Probably a lot 669 more.]] 671 8. References 673 8.1. Normative References 675 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 676 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 677 . 679 [BUNDLE] Yasskin, J., "Bundled HTTP Exchanges", Work in Progress, 680 Internet-Draft, draft-yasskin-wpack-bundled-exchanges-02, 681 26 September 2019, . 684 [HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP 685 Semantics", Work in Progress, Internet-Draft, draft-ietf- 686 httpbis-semantics-07, 7 March 2020, . 689 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 690 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 691 DOI 10.17487/RFC7540, May 2015, 692 . 694 [NI] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 695 Keranen, A., and P. Hallam-Baker, "Naming Things with 696 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 697 . 699 [ORIGIN] Barth, A., "The Web Origin Concept", RFC 6454, 700 DOI 10.17487/RFC6454, December 2011, 701 . 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 709 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 710 May 2017, . 712 [SH] Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 713 Work in Progress, Internet-Draft, draft-ietf-httpbis- 714 header-structure-14, 28 January 2020, 715 . 718 [SXG] Yasskin, J., "Signed HTTP Exchanges", Work in Progress, 719 Internet-Draft, draft-yasskin-http-origin-signed- 720 responses-08, 4 November 2019, . 724 8.2. Informative References 726 [CLEAR-DATA] 727 West, M., "Clear Site Data", W3C ED, 13 November 2017, 728 . 730 [DIGEST] Polli, R. and L. Pardue, "Digest Headers", Work in 731 Progress, Internet-Draft, draft-ietf-httpbis-digest- 732 headers-01, 3 November 2019, . 735 [HTML] WhatWG, ., "HTML", WhatWG Living Standard, 4 March 2020, 736 . 738 [IF-DIGEST] 739 Thomson, M., "Conditional HTTP Requests Using Digests", 740 Work in Progress, Internet-Draft, draft-thomson-http-if- 741 digest-00, 9 March 2020, . 744 [INDEXEDDB] 745 Alabbas, A. and J. Bell, "Indexed Database API 3.0", 746 W3C ED, 29 February 2020, 747 . 749 [LOADING] Yasskin, J., "Loading Signed Exchanges", 21 February 2020, 750 . 752 [PERMISSIONS] 753 Lamouri, M., Cáceres, M., and J. Yasskin, "Permissions", 754 W3C ED, 30 October 2019, 755 . 757 [SERVICE-WORKERS] 758 Russell, A., Song, J., Archibald, J., and M. 759 Kruisselbrink, "Service Workers 1", W3C ED, 24 February 760 2020, . 762 [SHA-2] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 763 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 764 DOI 10.17487/RFC6234, May 2011, 765 . 767 [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger, 768 "Subresource Integrity", W3C ED, 4 January 2020, 769 . 771 [SRI-ADDRESSABLE] 772 Hill, B., "Subresource Integrity Addressable Caching", 15 773 October 2016, . 776 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 777 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 778 . 780 [UNSIGNED] Yasskin, J., "Navigation to Unsigned Web Bundles", 20 781 February 2020, 782 . 785 Acknowledgments 787 This work is hardly original, nor is it an individual effort. 788 [[TODO: acknowledge.]] 790 Author's Address 792 Martin Thomson 793 Mozilla 795 Email: mt@lowentropy.net