Add preliminary description of how we integrate with cookies (#145)

Closes #31

Co-authored-by: Anne van Kesteren <[email protected]>

storage-access.bs

@@ -29,6 +29,11 @@ urlPrefix: https://tc39.github.io/ecma262/; spec: ECMASCRIPT
     text: agent cluster; url: #sec-agent-clusters; type: dfn
 urlPrefix: https://infra.spec.whatwg.org/; spec: INFRA
     text: implementation-defined; url: #implementation-defined; type: dfn
+urlPrefix: https://fetch.spec.whatwg.org/; spec: Fetch
+    text: http-network-or-cache fetch; url: #concept-http-network-or-cache-fetch; type: dfn
+spec: RFC6265; urlPrefix: https://tools.ietf.org/html/rfc6265
+    type: dfn
+        text: cookie store; url: section-5.3
 urlPrefix: https://w3c.github.io/webdriver/webdriver-spec.html#; spec: webdriver
     type: dfn
         text: current browsing context; url: dfn-current-browsing-context
@@ -286,12 +291,18 @@ ISSUE(privacycg/storage-access#137): Add links to current entry and session hist
 
 <h3 id="storage">Changes to various client-side storage mechanisms</h3>
 
-ISSUE(privacycg/storage-access#4): Should this API affect client-side storage other than cookies?
-
-ISSUE(privacycg/storage-access#31): Write this section. For each kind of client-side storage affected, modify them to invoke [=determine if a site has storage access=] & modify their behavior based on the result.
+This API only impacts HTTP cookies. A future revision of this API might impact other client-side state. [[!RFC6265]]
 
 <h4 id="cookies">Cookies</h4>
 
+This API is intended to be used with environments and user agent configurations that block access to unpartitioned cookies in a [=third party context=]. At the time of this writing, this concept has not yet been integrated into the [=HTTP-network-or-cache fetch=] and {{Document/cookie}} algorithms. To allow for such an integration, the [=cookie store=] will need to be modified to receive information about the top-level and embedded site of the request (to determine whether to attach cross-site, partitioned, or no cookies) as well as whether the request was made for a document that has storage access, through running the [=determine if a site has storage access=] algorithm that is defined in this specification.
+
+Once the cookie store allows for receiving information about storage access, we would update [=HTTP-network-or-cache fetch=] and {{Document/cookie}} to run [=determine if a site has storage access=] and pass this information to the [=cookie store=] when retrieving cookies.
+
+When getting unpartitioned cookies from the [=cookie store=] with storage access, user agents will still follow applicable `SameSite` restrictions (i.e., not attach cookies marked `SameSite=Strict` or `SameSite=Lax` in [=third party contexts=]).
+
+Note: User agents could apply different default values for the `SameSite` cookie attribute. This could lead to unpartitioned cookies without a `SameSite` attribute being attached to requests in some user agents (where `SameSite=None` is the default), but not in others (where `SameSite=Lax` is the default). Web developers are encouraged to set the `SameSite` attribute on their cookies to not run into issues.
+
 <h3 id="sandboxing-storage-access">Sandboxing storage access</h3>
 
 A [=sandboxing flag set=] has a <dfn export>sandbox storage access by user activation flag</dfn>. This flag prevents content from requesting storage access.