From 2e4dda5cabc0c9afab3e1183471266607be543be Mon Sep 17 00:00:00 2001 From: Robbie McElrath Date: Mon, 8 Jul 2024 16:39:38 -0700 Subject: [PATCH 1/5] Add non-normative sections to spec --- isolated-contexts.bs | 154 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 122 insertions(+), 32 deletions(-) diff --git a/isolated-contexts.bs b/isolated-contexts.bs index f4179f1..dc5c7f1 100644 --- a/isolated-contexts.bs +++ b/isolated-contexts.bs @@ -57,47 +57,137 @@ urlPrefix: https://w3c.github.io/webappsec-csp/; spec:CSP3 # Introduction # {#introduction} -Many powerful capabilities cannot safely be enabled in the Web Platform as it -is defined today. Some may break the platform's fundamental security -primitives, others may be too complex or technical to expect users to make -informed decisions about. Exposing these capabilities requires establishing -more trust in a page's content than the web can currently provide. -[Isolated Web Apps](https://github.com/WICG/isolated-web-apps) define one method -of establishing this trust by requiring third-party attestation before -enabling particularly powerful capabilities. +Throughout its existence the web has been evolved into an increasingly capable +application platform. Secure Contexts formalize transport security, Cross +Origin Isolation mitigates side-channel attacks, and device-specific permission +prompts make device access more scoped and understandable to users. Each of +these advancements either improved the safety guarantees of the web platform, +or guided users towards a more accurate expection of a page's behavior, and +unlocked new classes of capabilities that could be brought safely to the web. + +Despite these advancements, there are some APIs that still cannot safely be +exposed to the web because they violate the web's security primitives in a way +that cannot reasonably be addressed, or cannot be explained clearly enough for +users to make an informed decision about whether or not to grant a site access +to them. If the platform cannot prove that exposing an API to a particular site +is safe, then trust must derive from external attestations. + +Any assertion about the safety or behavior of a page requires knowing the +contents and behavior of the page; attestations are only meaningful if the code +that was vouched for is the same code being executed. Because of this, any +system that delegates trust decisions must be able to verify the integrity of +the code it is running — it must know that it matches the code that was +delegated trust. + +Additionally, capabilities that don't fit within the web's current security +model have the potential to pose a risk to other web content. This risk is +bidirectional: sandbox-piercing capabilities could be used to attack other +sites, and having access to powerful capabilities makes a site a more +attractive target for bad actors. To mitigate these risks, any content that is +granted access to a capability through the mechanisms described in this +specification must be isolated from a user's normal browsing session. + +This specification defines Isolated Contexts, which are environments +that meet a minimum standard of integrity and isolation, and provide a means of +auditing web content for the purpose of trustworthiness attestation, and +isolate this content from the rest of the user's browsing data. + +While this specification focuses on user-agent provided capabilities, Isolated +Contexts could be beneficial for any web page functionality whose threat model +isn't satisfied by the web's security model. For example, the threat model of +some end-to-end encrypted chat applications includes server compromise, which +is not protected against by the web today. The auditability and attestation +enabled by Isolated Contexts could allow these applications to have confidence +in the integrity and providence of the code they are running. + + +# Isolated Contexts # {#isolated-context-info} + +[=Isolated Contexts=] are defined through a series of [[#monkey]] to existing +specifications. + +Integrity is verified through a combination of strict [[CSP]], which ensures +cross-origin executable content cannot be loaded, and an integrity verification +algorithm, which is an abstracts mechanism to validate content loaded within a +page. This specification does not mandate a specific validation approach, it +only defines how one would be used to determine if an environment is an +Isolated Context. + + + +## Which APIs should require an Isolated Context? ## {#which-apis} + +As few as possible. Any API that can only be exposed to Isolated Contexts very +likely violates at least one + +design principle of the web, most commonly that + +it should be safe to visit a web page. Before gating an API on +IsolatedContext, consider the following questions: + +1. Is a new Web Platform API the only way to address the problems this API is + trying to solve? Web Extensions and native applications have their place. +1. If a capability cannot be communicated clearly to users, is there another + way to solve the problem that would be more understandable to users, and + allow them to make informed decisions about what content can access it? +1. Can the scope of the API be reduced such that it no longer poses an + unacceptable risk if exposed to an average web page? + +If no alternative can be found, requiring an API to run within an Isolated +Context can be considered as a last resort. + +Part of what makes the web such a unique and successful platform is its lack of +gatekeepers. Anyone can purchase a domain name and host their content without +approvals, and with full access to the Web Platform's API surface; everyone has +equal footing. The security guarantees provided by Isolated Contexts enable +auditability, which in turn enables attestation. This attestation, usually +third-party, is the main reason a browser vendor would restrict an API to +Isolated Contexts. Third-party attestation introduces gatekeepers to the Web +Platform, which is not a desirable direction for the platform to move. Browser +vendors must be extremely selective about which APIs they allow in Isolated +Contexts; changing an API so it can be used in a Secure Context should be +strongly preferred whenever possible. + + +## UI Treatment ## {#ui-treatment} + +This specification focuses on the technical requirements needed to achieve +integrity and isolation, but if Isolated Contexts are being used to enable +powerful capabilities, it is also critical to not violate user expectations. + +Users trust the web because they've been taught that web pages are safe, have +limited access to their device, and that they are in control of this access. All +APIs on the Web Platform have been carefully designed towards this end, with a +goal of ensuring that + +it should be safe to visit a web page. + +Browser vendors should consider whether capabilities restricted to Isolated +Contexts would violate a user's expectation of what a web page is capable of +doing. Violating these expectations would not only damage trust in the site, but +has the risk of damaging a user's trust in the Web Platform as a whole. + +To mitigate this, steps should be taken by the user agent to convey to users +that content running within an Isolated Context is not typical web content. This +could involve an installation flow, or a Web App UI treatment. -Deciding whether a page is trusted enough to access powerful capabilities -requires knowing the contents and behavior of the page; attestations of trust -are only meaningful if the code being vouched for is the same code being -executed. Because of this, any system seeking to delegate trust decisions within -a page must provide a method of validating the integrity of the page and the -executable content within it. -Additionally, content utilizing powerful capabilities must be isolated from -a user's default browsing session. This is to both protect traditional web -sites from potentially sandbox-piercing capabilities, and to protect the -page using powerful capabilities from attack from traditional web pages. - -This specification defines a method of establishing these properties, integrity -and isolation, in web content. - - -# Isolated Contexts # {#isolated-contexts} +# Monkey Patches # {#monkey} -[=Isolated contexts=] define a minimum standard of isolation and integrity for -executable content within a web page. They are defined through a series of -monkey patches to existing specifications: +This specification makes the following monkey patches to existing +specifications: * [[CSP]] will define the characteristics of a policy that's robust enough to - meaningfully defend against attack. It builds on what we've learned from - explorations like [[strict-csp]] and [[securer-contexts]], pushing - developers towards well-understood and valuable defenses. + meaningfully defend against attack, and enforce that cross-origin content + cannot be loaded. It builds on what we've learned from explorations like + [[strict-csp]] and [[securer-contexts]], pushing developers towards + well-understood and valuable defenses. * [[HTML]] will define the ways in which those CSP characteristics, along with other security requirements, are evaluated within a given context, similar conceptually to [=secure context=] and [=environment settings object/cross-origin isolated capability=]. It will additionally define - [=browsing context group=] properties needed to verify the integrity of + [=user agent=] properties needed to verify the integrity of an [=origin=]'s resources. * [[FETCH]] will add integrity verification to the [=fetch=] algorithm. @@ -109,7 +199,6 @@ monkey patches to existing specifications: * [[STORAGE]] will define the double-keying requirements of [=Isolated Contexts=]. -# Monkey Patches # {#monkey} ## Content Security Policy ## {#monkey-csp} @@ -590,6 +679,7 @@ after similarly handling [{{CrossOriginIsolated}}] (step 4 below). + ## Storage ## {#monkey-storage} The [=obtain a storage key for non-storage purposes=] algorithm is extended to From 664d5d72bc92df73579172357919a55d0d1b92f0 Mon Sep 17 00:00:00 2001 From: Robbie McElrath Date: Fri, 9 Aug 2024 17:05:27 -0700 Subject: [PATCH 2/5] Incorporate most IsolatedContext review feedback (#43) This incorporates most of @domfarolino's feedback from issue #42. It doesn't address the biggest issue about going from environment settings object to browsing context group, which will be in another PR. --- isolated-contexts.bs | 79 +++++++++++++++++++++++++++----------------- 1 file changed, 49 insertions(+), 30 deletions(-) diff --git a/isolated-contexts.bs b/isolated-contexts.bs index dc5c7f1..b615e14 100644 --- a/isolated-contexts.bs +++ b/isolated-contexts.bs @@ -38,6 +38,9 @@ spec:webidl; type:dfn; text:namespace urlPrefix: https://w3c.github.io/webappsec-csp/; spec:CSP3 type: abstract-op text: Get fetch directive fallback list; url: #directive-fallback-list +urlPrefix: https://w3c.github.io/trusted-types/dist/spec/; spec:trusted-types + type: dfn + text: require-trusted-types-for-directive 
 {
@@ -213,7 +216,8 @@ is the core entry point CSP will expose to HTML.
 A [=CSP list=] |policies| is said to
 meaningfully
 mitigate injection attacks if the following algorithm returns
-"`Meaningful`":
+"`Meaningful`". Possible return values are "`Meaningful`" and
+"`Not meaningful enough`".
 
 
    
     1.  Let |meets object requirements|, |meets base requirements|,
@@ -279,7 +283,8 @@ the active directive given a [=policy=] |policy| and a |directive name|:
 
 
    
 A [=policy=] |policy| sufficiently mitigates plugins if
-the following algorithm returns "`Sufficient`":
+the following algorithm returns "`Sufficient`". Possible return values are
+"`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  Obtain |active directive| from
@@ -290,7 +295,8 @@ the following algorithm returns "`Sufficient`":
         *   |active directive| is not null
         *   |active directive|'s [=directive/value=]'s [=set/size=] is 1
         *   |active directive|'s [=directive/value=][0] is an
-            [=ASCII case-insensitive=] match for the string "`'none'`".
+            [=ASCII case-insensitive=] match for the string
+            "`'none'`".
 
     1.  Return "`Not sufficient`".
 
    
@@ -300,7 +306,8 @@ the following algorithm returns "`Sufficient`":
 
 
    
 A [=policy=] |policy| sufficiently mitigates relative URL
-manipulation if the following algorithm returns "`Sufficient`":
+manipulation if the following algorithm returns "`Sufficient`".
+Possible return values are "`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  [=For each=] |directive| in |policy|'s [=policy/directive set=]:
@@ -311,7 +318,7 @@ manipulation if the following algorithm returns "`Sufficient`":
             *   |directive|'s [=directive/value=]'s [=set/size=] is 1
             *   |directive|'s [=directive/value=][0] is an
                 [=ASCII case-insensitive=] match for either the string
-                "`'none'`" or the string "`'self'`".
+                "`'none'`" or the string "`'self'`".
 
     1.  Return "`Not sufficient`".
 
    
@@ -321,7 +328,8 @@ manipulation if the following algorithm returns "`Sufficient`":
 
 
    
 A [=policy=] |policy| sufficiently mitigates script execution
-if the following algorithm returns "`Sufficient`":
+if the following algorithm returns "`Sufficient`".
+Possible return values are "`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  Obtain |active directive| from
@@ -331,8 +339,9 @@ if the following algorithm returns "`Sufficient`":
 
         *   |active directive| is not null
         *   All [=source expressions=] in |active directive| are an
-            [=ASCII case-insensitive=] match for the strings "`'none'`",
-            "`'self'`", or "`'wasm-unsafe-eval'`".
+            [=ASCII case-insensitive=] match for the strings
+            "`'none'`", "`'self'`", or
+            "`'wasm-unsafe-eval'`".
 
     1.  Return "`Not sufficient`".
 
    
@@ -342,7 +351,8 @@ if the following algorithm returns "`Sufficient`":
 
 
    
 A [=policy=] |policy| sufficiently mitigates style evaluation if
-the following algorithm returns "`Sufficient`":
+the following algorithm returns "`Sufficient`".
+Possible return values are "`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  [=For each=] |directive| in |policy|'s [=policy/directive set=]:
@@ -353,8 +363,9 @@ the following algorithm returns "`Sufficient`":
 
             *   |directive|'s [=directive/name=] is "`style-src`".
             *   All [=source expressions=] in |active directive| are an
-                [=ASCII case-insensitive=] match for the strings "`'none'`",
-                "`'self'`", or "`'unsafe-inline'`".
+                [=ASCII case-insensitive=] match for the strings
+                "`'none'`", "`'self'`", or
+                "`'unsafe-inline'`".
 
     1.  Return "`Not sufficient`".
 
    
@@ -364,7 +375,8 @@ the following algorithm returns "`Sufficient`":
 
 
    
 A [=policy=] |policy| sufficiently blocks insecure
-subresources if the following algorithm returns "`Sufficient`":
+subresources if the following algorithm returns "`Sufficient`".
+Possible return values are "`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  [=For each=] |directive name| in the set [`frame-src`, `connect-src`,
@@ -372,10 +384,10 @@ subresources if the following algorithm returns "`Sufficient`":
         1.  Obtain |active directive|
             from |policy|, given |directive name|.
 
-        1.  Return "`not sufficient`" if any [=source expression=] in
+        1.  Return "`Not sufficient`" if any [=source expression=] in
             |active directive| is **not** an [=ASCII case-insensitive=] match
-            for the strings "`'none'`", "`'self'`", "`https:`", "`blob:`",
-            or "`data:`".
+            for the strings "`'none'`", "`'self'`",
+            "`https:`", "`blob:`", or "`data:`".
 
     1.  Return "`Sufficient`"
 
    
@@ -385,7 +397,8 @@ subresources if the following algorithm returns "`Sufficient`":
 
 
    
 A [=policy=] |policy| sufficiently mitigates DOM sinks
-if the following algorithm returns "`Sufficient`":
+if the following algorithm returns "`Sufficient`".
+Possible return values are "`Sufficient`" and "`Not sufficient`".
 
 
      
     1.  [=For each=] |directive| in |policy|'s [=policy/directive set=]:
@@ -393,7 +406,8 @@ if the following algorithm returns "`Sufficient`":
         1.  Return "`Sufficient`" if all of the following are true:
 
             *   |directive|'s [=directive/name=] is
-                "`require-trusted-types-for`". [[!TRUSTED-TYPES]]
+                "[=require-trusted-types-for-directive|require-trusted-types-for=]".
+                [[!TRUSTED-TYPES]]
             *   |directive|'s [=directive/value=] [=set/contains=][0] an
                 [=ASCII case-insensitive=] match for the string "`'script'`".
 
@@ -427,7 +441,8 @@ require-trusted-types-for 'script';
 A [=CSP list=] |policies| is said to
 meaningfully
 mitigate UI Redressing attacks [[UISECURITY]] if the following algorithm
-returns "`Meaningful`":
+returns "`Meaningful`".
+Possible return values are "`Meaningful`" and "`Not meaningful enough`".
 
 
        
     1.  [=For each=] |policy| in |policies|:
@@ -444,7 +459,7 @@ returns "`Meaningful`":
                 *   |directive|'s [=directive/value=]'s [=set/size=] is 1
                 *   |directive|'s [=directive/value=][0] is an
                     [=ASCII case-insensitive=] match for either the string
-                    "`'none'`" or the string "`'self'`".
+                    "`'none'`" or the string "`'self'`".
 
     1. Return "`Not meaningful enough`".
 
      
@@ -466,10 +481,11 @@ A [=browsing context group=] has an 
 integrity origin, which is an [=origin=] or `null`.
 
 A [=browsing context group=] has an 
-integrity verification algorithm, which is `null` or a [=user agent=]
-defined algorithm that accepts a [=request=] and a [=response=], and returns a
-[=boolean=]. A [=browsing context group=]'s [=integrity verification algorithm=]
-MUST be non-null if its [=integrity origin=] is non-null.
+integrity verification algorithm, which is `null` or an
+[=implementation-defined=] algorithm that accepts a [=request=] and a
+[=response=], and returns a [=boolean=]. A [=browsing context group=]'s
+[=integrity verification algorithm=] MUST be non-null if its
+[=integrity origin=] is non-null.
 
 Note: A typical [=integrity verification algorithm=] might verify that a
 response body hashes to an expected value, or that it originated from a known
@@ -504,14 +520,16 @@ An [=environment settings object=] |environment| is an
         |environment| belongs to.
     1.  If |environment| does not [=environment settings object/meaningfully
         mitigate injection attacks=], return `false`.
-    1.  If |browsing context group|'s [=cross-origin isolated capability=] is
-        not [=concrete=], return `false`.
+    1.  If |environment|'s [=cross-origin isolated capability=] is not
+        [=concrete=], return `false`.
     1.  If |environment| does not [=environment settings object/mitigate UI
         Redressing attacks=], return `false`.
     1.  If |browsing context group|'s [=browsing context group/integrity
         origin=] is null, return `false`.
-    1.  If |environment|'s [=origin=] is not equal to [=browsing context group/
-        integrity origin=], return `false`.
+    1.  Let |integrity origin| be |browsing context group|'s
+        [=browsing context group/integrity origin=].
+    1.  If |environment|'s [=origin=] is not [=same origin=] with |integrity
+        origin|, return `false`.
     1.  Return `true`.
 
    
 
@@ -524,7 +542,8 @@ In Fetch, we'll use the [=integrity verification algorithm=] defined in
 ### Verify the integrity of a response ### {#fetch-verify-response}
 
    
 To verify the integrity of a response given a [=request=] |request|
-and a [=response=] |response|:
+and a [=response=] |response|, run these steps. Possible return values are
+"`not applicable`", "`invalid`", or "`valid`".
 
 
      
   
    1. Let |client| be |request|'s [=request/client=].
      2. 
@@ -545,8 +564,8 @@ and a [=response=] |response|:
     return "`not applicable`".
   
   
    2. 
-    If |request|'s [=request/origin=] is not equal to |integrity origin|,
-    return "`not applicable`".
+    If |request|'s [=request/origin=] is not [=same origin=] with |integrity
+    origin|, return "`not applicable`".
   
      3. 
   
    3. 
     If |response|'s [=response/body=] is `null`, return "`invalid`".

From 9e446f8c3b54cc5bf018d12a8a929f1fe91db62f Mon Sep 17 00:00:00 2001
From: Vincent Scheib 
Date: Fri, 9 Aug 2024 17:06:41 -0700
Subject: [PATCH 3/5] Add links to sub-explainers and specification to top
 level README.md (#47)

---
 README.md | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index de8f9ea..2b36769 100644
--- a/README.md
+++ b/README.md
@@ -4,6 +4,12 @@
 
 This document proposes a way of building applications using web standard technologies that will have useful security properties unavailable to normal web pages. They are tentatively called Isolated Web Apps (IWAs). Rather than being hosted on live web servers and fetched over HTTPS, these applications are packaged into [Web Bundles](https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html), signed by their developer, and distributed to end-users through one or more of the potential methods described below.
 
+Additional documents in this repo:
+*   [Permissions Explainer](./Permissions.md) describes `permissions_policy` manifest field and interaction with the `Permissions-Policy` header.
+*   [Scheme Explainer](./Scheme.md) describes the `isolated-app:` scheme and signed web bundlge IDs.
+*   [Updates Explainer](./Updates.md) describes the `version`, `update_manifest_url` manifest fields and updating process.
+*   [Isolated Contexts Specification](https://wicg.github.io/isolated-web-apps/isolated-contexts.html) 
+
 ## Motivating Use Cases
 
 Content Security Policy (CSP) provides strong protection against cross-site scripting (XSS) vulnerabilities. Transport Layer Security (TLS) and Subresource Integrity (SRI) provide protection against resources being tampered with in transit or when hosted on third-party servers. However, the threat model for some particularly security sensitive applications includes the main application server itself being compromised and serving malicious content. This goes beyond the protections that current policies can provide. An environment stricter than [[SECURE-CONTEXT]](https://w3c.github.io/webappsec-secure-contexts/) is therefore required.
@@ -22,7 +28,7 @@ The core of this proposal is making application updates explicit. Unlike TLS key
 
 The reason for this is both practical and philosophical. If the identity of the site were still based on a DNS name, then it would still be vulnerable to a temporary loss of control over that domain or the infrastructure used to validate ownership of the domain. Philosophically, we also want to avoid building an alternative to certificate authorities which shares the same namespace. Isolated Web Apps therefore use a new scheme (tentatively, `isolated-app://`) where the authority section of the URL is based on the public key used to sign the Web Bundle containing the application resources. More details available in the [Scheme Explainer](./Scheme.md).
 
-An application can be upgraded by replacing its Web Bundle with a new version signed by the same key. Since the key hash is the same, the application retains any local storage associated with the previous version. To prevent downgrade attacks, implementations may require either a `"version"` field in the [Web Application Manifest](https://www.w3.org/TR/appmanifest/), or the signature timestamp to be monotonically increasing.
+An application can be upgraded by replacing its Web Bundle with a new version signed by the same key. Since the key hash is the same, the application retains any local storage associated with the previous version. To prevent downgrade attacks, implementations may require either a [`version`](./Updates.md) [Web Application Manifest](https://www.w3.org/TR/appmanifest/) field, or the signature timestamp to be monotonically increasing.
 
 The protection against server compromise would be no good if the application could be tricked into loading malicious content from outside its Web Bundle, and so a rigorous Content Security Policy is applied,
 

From 006e9fef2ff0fcc5b7c3a7379ef02c9289ae178a Mon Sep 17 00:00:00 2001
From: Robbie McElrath 
Date: Fri, 9 Aug 2024 17:16:49 -0700
Subject: [PATCH 4/5] Redo integrity verification in IsolatedContext spec (#44)

This addresses the issues raised by @domfarolino in #42 regarding how the spec was tying integrity verification to browsing context group. Rather than attaching integrity verification information to browsing context group, which doesn't exist for all environments, this moves the information to a user agent level map.
---
 isolated-contexts.bs | 71 +++++++++++++++++++-------------------------
 1 file changed, 31 insertions(+), 40 deletions(-)

diff --git a/isolated-contexts.bs b/isolated-contexts.bs
index b615e14..d76edd9 100644
--- a/isolated-contexts.bs
+++ b/isolated-contexts.bs
@@ -477,20 +477,25 @@ the associated [=environment settings object/global object=].
 
 ### Integrity ### {#html-integrity}
 
-A [=browsing context group=] has an 
-integrity origin, which is an [=origin=] or `null`.
-
-A [=browsing context group=] has an 
-integrity verification algorithm, which is `null` or an
+An integrity verification algorithm is an
 [=implementation-defined=] algorithm that accepts a [=request=] and a
-[=response=], and returns a [=boolean=]. A [=browsing context group=]'s
-[=integrity verification algorithm=] MUST be non-null if its
-[=integrity origin=] is non-null.
+[=response=], and returns a [=boolean=].
 
 Note: A typical [=integrity verification algorithm=] might verify that a
 response body hashes to an expected value, or that it originated from a known
 bundle of resources.
 
+A [=user agent=] holds an origin integrity verification map,
+which is a [=map=] of [=tuple origins=] to
+[=integrity verification algorithms=].
+
+Note: How user agents populate the [=origin integrity verification map=] is
+outside the scope of this specification, which is focused on the properties
+needed to establish integrity and isolation.
+Isolated Web Apps
+provide one possible implementation by basing this map on the set of installed
+Isolated Web Apps.
+
 ### Environment Settings Object properties ### {#html-environment-properties}
 
 
      
@@ -516,20 +521,15 @@ these properties will not mutate during an environment's lifetime.
 
      
 An [=environment settings object=] |environment| is an
 isolated context if the following algorithm returns `true`:
-    1.  Let |browsing context group| be the [=browsing context group=] that 
-        |environment| belongs to.
     1.  If |environment| does not [=environment settings object/meaningfully
         mitigate injection attacks=], return `false`.
-    1.  If |environment|'s [=cross-origin isolated capability=] is not
-        [=concrete=], return `false`.
+    1.  If |environment|'s [=cross-origin isolated capability=] is
+        not [=concrete=], return `false`.
     1.  If |environment| does not [=environment settings object/mitigate UI
         Redressing attacks=], return `false`.
-    1.  If |browsing context group|'s [=browsing context group/integrity
-        origin=] is null, return `false`.
-    1.  Let |integrity origin| be |browsing context group|'s
-        [=browsing context group/integrity origin=].
-    1.  If |environment|'s [=origin=] is not [=same origin=] with |integrity
-        origin|, return `false`.
+    1.  Let |origin| be |environment|'s [=origin=].
+    1.  If the [=user agent=]'s [=origin integrity verification map=][|origin|]
+        does not [=map/exist=], return `false`.
     1.  Return `true`.
 
      
 
@@ -548,24 +548,14 @@ and a [=response=] |response|, run these steps. Possible return values are
 
        
   
      1. Let |client| be |request|'s [=request/client=].
        2. 
   
      2. If |client| is `null`, return "`not applicable`".
        3. 
+  
      3. Let |origin| be |request|'s [=request/origin=].
        4. 
   
      4. 
-    Let |browsing context group| be the [=browsing context group=] that
-    |client| belongs to.
+    If the [=user agent=]'s [=origin integrity verification map=][|origin|]
+    does not [=map/exist=], return "`not applicable`".
   
        5. 
   
      5. 
-    Let |integrity origin| be |browsing context group|'s [=integrity origin=].
-  
        6. 
-  
      6. 
-    Let |integrity verification algorithm| be |browsing context group|'s
-    [=integrity verification algorithm=].
-  
        7. 
-  
      7. 
-    If |integrity origin| or |integrity verification algorithm| are `null`,
-    return "`not applicable`".
-  
        8. 
-  
      8. 
-    If |request|'s [=request/origin=] is not [=same origin=] with |integrity
-    origin|, return "`not applicable`".
+    Let |integrity verification algorithm| be the [=user agent=]'s
+    [=origin integrity verification map=][|origin|].
   
        9. 
   
      9. 
     If |response|'s [=response/body=] is `null`, return "`invalid`".
@@ -702,8 +692,10 @@ after similarly handling [{{CrossOriginIsolated}}] (step 4 below).
 ## Storage ## {#monkey-storage}
 
 The [=obtain a storage key for non-storage purposes=] algorithm is extended to
-require double-keying on all storage within a [=browsing context group=]
-containing [=Isolated Contexts=].
+require double-keying on all storage belonging to an
+
+environment with a [=top-level origin=] known by the [=user agent=] to have
+an [=integrity verification algorithm=].
 
 
        
 To obtain a storage key for non-storage purposes, given an
@@ -718,13 +710,12 @@ environment |environment|, run these steps:
     
        10. 
 
     
      10. 
-      Let |integrity origin| be the [=browsing context group/integrity origin=]
-      of the [=browsing context group=] that |environment| belongs to.
+      Let |top-level origin| be |environment|'s [=top-level origin=].
     
        11. 
-
     
      11. 
-      If |integrity origin| is non-null, return a [=tuple=] consisting of
-      |integrity origin| and |origin|.
+      If the [=user agent=]'s [=origin integrity verification map=]
+      [|top-level origin|] [=map/exists=], return a [=tuple=] consisting of
+      |top-level origin| and |origin|.
     
        12. 
 
     
      12. 

From 13b7789a793f085b9fc6a0f2ee0cf328d6949a53 Mon Sep 17 00:00:00 2001
From: Robbie McElrath 
Date: Fri, 9 Aug 2024 17:26:35 -0700
Subject: [PATCH 5/5] Address Reilly's comments

---
 isolated-contexts.bs | 33 ++++++++++++++++++---------------
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/isolated-contexts.bs b/isolated-contexts.bs
index d76edd9..bac79fa 100644
--- a/isolated-contexts.bs
+++ b/isolated-contexts.bs
@@ -61,12 +61,15 @@ urlPrefix: https://w3c.github.io/trusted-types/dist/spec/; spec:trusted-types
 # Introduction # {#introduction}
 
 Throughout its existence the web has been evolved into an increasingly capable
-application platform. Secure Contexts formalize transport security, Cross
-Origin Isolation mitigates side-channel attacks, and device-specific permission
-prompts make device access more scoped and understandable to users. Each of
-these advancements either improved the safety guarantees of the web platform,
-or guided users towards a more accurate expection of a page's behavior, and
-unlocked new classes of capabilities that could be brought safely to the web.
+application platform. [=Secure Contexts=] formalize transport security,
+[=environment settings object/cross-origin isolated capability|Cross Origin
+Isolation=] mitigates side-channel attacks, and browsers and operating systems
+have experimented with permission interfaces based on selecting particular
+files and devices to make access more scoped and understandable to users. Each
+of these advancements either improved the safety guarantees of the web
+platform, or guided users towards a more accurate expection of a page's
+behavior, and unlocked new classes of capabilities that could be brought safely
+to the web.
 
 Despite these advancements, there are some APIs that still cannot safely be
 exposed to the web because they violate the web's security primitives in a way
@@ -111,13 +114,12 @@ specifications.
 
 Integrity is verified through a combination of strict [[CSP]], which ensures
 cross-origin executable content cannot be loaded, and an integrity verification
-algorithm, which is an abstracts mechanism to validate content loaded within a
+algorithm, which is an abstract mechanism to validate content loaded within a
 page. This specification does not mandate a specific validation approach, it
 only defines how one would be used to determine if an environment is an
 Isolated Context.
 
 
-
 ## Which APIs should require an Isolated Context? ## {#which-apis}
 
 As few as possible. Any API that can only be exposed to Isolated Contexts very
@@ -125,8 +127,8 @@ likely violates at least one
 
 design principle of the web, most commonly that
 
-it should be safe to visit a web page. Before gating an API on
-IsolatedContext, consider the following questions:
+it should be safe to visit a web page. Before requiring an Isolated Context
+to use an API, consider the following questions:
 
 1.  Is a new Web Platform API the only way to address the problems this API is
     trying to solve? Web Extensions and native applications have their place.
@@ -141,11 +143,12 @@ Context can be considered as a last resort.
 
 Part of what makes the web such a unique and successful platform is its lack of
 gatekeepers. Anyone can purchase a domain name and host their content without
-approvals, and with full access to the Web Platform's API surface; everyone has
-equal footing. The security guarantees provided by Isolated Contexts enable
-auditability, which in turn enables attestation. This attestation, usually
-third-party, is the main reason a browser vendor would restrict an API to
-Isolated Contexts. Third-party attestation introduces gatekeepers to the Web
+anyone else's approval, and with full access to the Web Platform's API surface;
+everyone has equal footing. The security guarantees provided by Isolated
+Contexts enable auditability, which in turn enables attestation. The safety
+provided by attestation, either by the browser vendor or a third-party, is the
+main reason an API would be restricted to Isolated Contexts. Parties providing
+attestation services have the potential to become gatekeepers to the Web
 Platform, which is not a desirable direction for the platform to move. Browser
 vendors must be extremely selective about which APIs they allow in Isolated
 Contexts; changing an API so it can be used in a Secure Context should be