draft-ietf-httpbis-rfc6265bis-04.txt   draft-ietf-httpbis-rfc6265bis-05.txt 
HTTP M. West, Ed. HTTP M. West, Ed.
Internet-Draft Google, Inc Internet-Draft Google, Inc
Obsoletes: 6265 (if approved) J. Wilander, Ed. Obsoletes: 6265 (if approved) J. Wilander, Ed.
Intended status: Standards Track Apple, Inc Intended status: Standards Track Apple, Inc
Expires: July 23, 2020 January 20, 2020 Expires: August 8, 2020 February 5, 2020
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-04 draft-ietf-httpbis-rfc6265bis-05
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 6265. on the Internet. This document obsoletes RFC 6265.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2020. This Internet-Draft will expire on August 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22
5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23 5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23
5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25 5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25
5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26 5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26
5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26
5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 27 5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 27
5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27
5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27
5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27
5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28
5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 34 5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33
6. Implementation Considerations . . . . . . . . . . . . . . . . 36 6. Implementation Considerations . . . . . . . . . . . . . . . . 35
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Application Programming Interfaces . . . . . . . . . . . 36 6.2. Application Programming Interfaces . . . . . . . . . . . 36
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 36 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 36
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 37 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 37
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 38 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 38 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 39 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 41 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 43 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 44 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 49 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 49 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 49 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 49
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 49 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 49
A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 50 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 50
A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 50 A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 6, line 41 skipping to change at page 6, line 41
"Service Workers" are defined in the Service Workers specification "Service Workers" are defined in the Service Workers specification
[SERVICE-WORKERS]. [SERVICE-WORKERS].
The term "origin", the mechanism of deriving an origin from a URI, The term "origin", the mechanism of deriving an origin from a URI,
and the "the same" matching algorithm for origins are defined in and the "the same" matching algorithm for origins are defined in
[RFC6454]. [RFC6454].
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
defined in Section 4.2.1 of [RFC7231]. defined in Section 4.2.1 of [RFC7231].
The term "public suffix" is defined in a note in Section 5.3 of A domain's "public suffix" is the portion of a domain that is
[RFC6265] as "a domain that is controlled by a public registry", and controlled by a public registry, such as "com", "co.uk", and
are also known as "effective top-level domains" (eTLDs). For "pvt.k12.wy.us" [PSL]. A domain's "registrable domain" is the
example, "site.example"'s public suffix is "com". User agents SHOULD domain's public suffix plus the label to its left. That is, for
use an up-to-date public suffix list, such as the one maintained by "https://www.site.example", the public suffix is "example", and the
Mozilla at [PSL]. registrable domain is "site.example". This concept is defined more
rigorously in [PSL], which specifies a formal algorithm to obtain
An origin's "registered domain" is the origin's host's public suffix both.
plus the label to its left. That is, for "https://www.site.example",
the public suffix is "example", and the registered domain is
"site.example". This concept is defined more rigorously in [PSL],
and is also known as "effective top-level domain plus one" (eTLD+1).
The term "request", as well as a request's "client", "current url", The term "request", as well as a request's "client", "current url",
"method", and "target browsing context", are defined in [FETCH]. "method", and "target browsing context", are defined in [FETCH].
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
skipping to change at page 20, line 33 skipping to change at page 20, line 33
o The cookie-path is a prefix of the request-path, and the last o The cookie-path is a prefix of the request-path, and the last
character of the cookie-path is %x2F ("/"). character of the cookie-path is %x2F ("/").
o The cookie-path is a prefix of the request-path, and the first o The cookie-path is a prefix of the request-path, and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. "Same-site" and "cross-site" Requests 5.2. "Same-site" and "cross-site" Requests
A request is "same-site" if its target's URI's origin's registered A request is "same-site" if its target's URI's origin's registrable
domain is an exact match for the request's client's "site for domain is an exact match for the request's client's "site for
cookies", or if the request has no client. The request is otherwise cookies", or if the request has no client. The request is otherwise
"cross-site". "cross-site".
For a given request ("request"), the following algorithm returns For a given request ("request"), the following algorithm returns
"same-site" or "cross-site": "same-site" or "cross-site":
1. If "request"'s client is "null", return "same-site". 1. If "request"'s client is "null", return "same-site".
Note that this is the case for navigation triggered by the user Note that this is the case for navigation triggered by the user
directly (e.g. by typing directly into a user agent's address directly (e.g. by typing directly into a user agent's address
bar). bar).
2. Let "site" be "request"'s client's "site for cookies" (as defined 2. Let "site" be "request"'s client's "site for cookies" (as defined
in the following sections). in the following sections).
3. Let "target" be the registered domain of "request"'s current url. 3. Let "target" be the registrable domain of "request"'s current
url.
4. If "site" is an exact match for "target", return "same-site". 4. If "site" is an exact match for "target", return "same-site".
5. Return "cross-site". 5. Return "cross-site".
The request's client's "site for cookies" is calculated depending The request's client's "site for cookies" is calculated depending
upon its client's type, as described in the following subsections: upon its client's type, as described in the following subsections:
5.2.1. Document-based requests 5.2.1. Document-based requests
The URI displayed in a user agent's address bar is the only security The URI displayed in a user agent's address bar is the only security
context directly exposed to users, and therefore the only signal context directly exposed to users, and therefore the only signal
users can reasonably rely upon to determine whether or not they trust users can reasonably rely upon to determine whether or not they trust
a particular website. The registered domain of that URI's origin a particular website. The registrable domain of that URI's origin
represents the context in which a user most likely believes represents the context in which a user most likely believes
themselves to be interacting. We'll label this domain the "top-level themselves to be interacting. We'll label this domain the "top-level
site". site".
For a document displayed in a top-level browsing context, we can stop For a document displayed in a top-level browsing context, we can stop
here: the document's "site for cookies" is the top-level site. here: the document's "site for cookies" is the top-level site.
For documents which are displayed in nested browsing contexts, we For documents which are displayed in nested browsing contexts, we
need to audit the origins of each of a document's ancestor browsing need to audit the origins of each of a document's ancestor browsing
contexts' active documents in order to account for the "multiple- contexts' active documents in order to account for the "multiple-
nested scenarios" described in Section 4 of [RFC7034]. A document's nested scenarios" described in Section 4 of [RFC7034]. A document's
"site for cookies" is the top-level site if and only if the document "site for cookies" is the top-level site if and only if the document
and each of its ancestor documents' origins have the same registered and each of its ancestor documents' origins have the same registrable
domain as the top-level site. Otherwise its "site for cookies" is domain as the top-level site. Otherwise its "site for cookies" is
the empty string. the empty string.
Given a Document ("document"), the following algorithm returns its Given a Document ("document"), the following algorithm returns its
"site for cookies" (either a registered domain, or the empty string): "site for cookies" (either a registrable domain, or the empty
string):
1. Let "top-document" be the active document in "document"'s 1. Let "top-document" be the active document in "document"'s
browsing context's top-level browsing context. browsing context's top-level browsing context.
2. Let "top-origin" be the origin of "top-document"'s URI if "top- 2. Let "top-origin" be the origin of "top-document"'s URI if "top-
document"'s sandboxed origin browsing context flag is set, and document"'s sandboxed origin browsing context flag is set, and
"top-document"'s origin otherwise. "top-document"'s origin otherwise.
3. Let "documents" be a list containing "document" and each of 3. Let "documents" be a list containing "document" and each of
"document"'s ancestor browsing contexts' active documents. "document"'s ancestor browsing contexts' active documents.
4. For each "item" in "documents": 4. For each "item" in "documents":
1. Let "origin" be the origin of "item"'s URI if "item"'s 1. Let "origin" be the origin of "item"'s URI if "item"'s
sandboxed origin browsing context flag is set, and "item"'s sandboxed origin browsing context flag is set, and "item"'s
origin otherwise. origin otherwise.
2. If "origin"'s host's registered domain is not an exact match 2. If "origin"'s host's registrable domain is not an exact match
for "top-origin"'s host's registered domain, return the empty for "top-origin"'s host's registrable domain, return the
string. empty string.
5. Return "top-origin"'s host's registered domain. 5. Return "top-origin"'s host's registrable domain.
5.2.2. Worker-based requests 5.2.2. Worker-based requests
Worker-driven requests aren't as clear-cut as document-driven Worker-driven requests aren't as clear-cut as document-driven
requests, as there isn't a clear link between a top-level browsing requests, as there isn't a clear link between a top-level browsing
context and a worker. This is especially true for Service Workers context and a worker. This is especially true for Service Workers
[SERVICE-WORKERS], which may execute code in the background, without [SERVICE-WORKERS], which may execute code in the background, without
any document visible at all. any document visible at all.
Note: The descriptions below assume that workers must be same-origin Note: The descriptions below assume that workers must be same-origin
skipping to change at page 22, line 38 skipping to change at page 22, line 38
worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
their "site for cookies" as that document's "site for cookies". their "site for cookies" as that document's "site for cookies".
Shared workers may be bound to multiple documents at once. As it is Shared workers may be bound to multiple documents at once. As it is
quite possible for those documents to have distinct "site for cookie" quite possible for those documents to have distinct "site for cookie"
values, the worker's "site for cookies" will be the empty string in values, the worker's "site for cookies" will be the empty string in
cases where the values diverge, and the shared value in cases where cases where the values diverge, and the shared value in cases where
the values agree. the values agree.
Given a WorkerGlobalScope ("worker"), the following algorithm returns Given a WorkerGlobalScope ("worker"), the following algorithm returns
its "site for cookies" (either a registered domain, or the empty its "site for cookies" (either a registrable domain, or the empty
string): string):
1. Let "site" be "worker"'s origin's host's registered domain. 1. Let "site" be "worker"'s origin's host's registrable domain.
2. For each "document" in "worker"'s Documents: 2. For each "document" in "worker"'s Documents:
1. Let "document-site" be "document"'s "site for cookies" (as 1. Let "document-site" be "document"'s "site for cookies" (as
defined in Section 5.2.1). defined in Section 5.2.1).
2. If "document-site" is not an exact match for "site", return 2. If "document-site" is not an exact match for "site", return
the empty string. the empty string.
3. Return "site". 3. Return "site".
skipping to change at page 23, line 19 skipping to change at page 23, line 19
Document which registered them. Document which registered them.
Requests which simply pass through a Service Worker will be handled Requests which simply pass through a Service Worker will be handled
as described above: the request's client will be the Document or as described above: the request's client will be the Document or
Worker which initiated the request, and its "site for cookies" will Worker which initiated the request, and its "site for cookies" will
be those defined in Section 5.2.1 and Section 5.2.2.1 be those defined in Section 5.2.1 and Section 5.2.2.1
Requests which are initiated by the Service Worker itself (via a Requests which are initiated by the Service Worker itself (via a
direct call to "fetch()", for instance), on the other hand, will have direct call to "fetch()", for instance), on the other hand, will have
a client which is a ServiceWorkerGlobalScope. Its "site for cookies" a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
will be the registered domain of the Service Worker's URI. will be the registrable domain of the Service Worker's URI.
Given a ServiceWorkerGlobalScope ("worker"), the following algorithm Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
returns its "site for cookies" (either a registered domain, or the returns its "site for cookies" (either a registrable domain, or the
empty string): empty string):
1. Return "worker"'s origin's host's registered domain. 1. Return "worker"'s origin's host's registrable domain.
5.3. The Set-Cookie Header 5.3. The Set-Cookie Header
When a user agent receives a Set-Cookie header field in an HTTP When a user agent receives a Set-Cookie header field in an HTTP
response, the user agent MAY ignore the Set-Cookie header field in response, the user agent MAY ignore the Set-Cookie header field in
its entirety. For example, the user agent might wish to block its entirety. For example, the user agent might wish to block
responses to "third-party" requests from setting cookies (see responses to "third-party" requests from setting cookies (see
Section 7.1). Section 7.1).
If the user agent does not ignore the Set-Cookie header field in its If the user agent does not ignore the Set-Cookie header field in its
skipping to change at page 28, line 28 skipping to change at page 28, line 28
cookies along with cross-site requests if and only if they are top- cookies along with cross-site requests if and only if they are top-
level navigations which use a "safe" (in the [RFC7231] sense) HTTP level navigations which use a "safe" (in the [RFC7231] sense) HTTP
method. method.
Lax enforcement provides reasonable defense in depth against CSRF Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but does not attacks that rely on unsafe HTTP methods (like "POST"), but does not
offer a robust defense against CSRF as a general category of attack: offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level 1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as navigations in order to create a "same-site" request (as
described in section 2.1), which is only a speedbump along the described in section 5.2.1), which is only a speedbump along the
road to exploitation. road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be 2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user exploited to create "same-site" requests without the risk of user
detection. detection.
When possible, developers should use a session management mechanism When possible, developers should use a session management mechanism
such as that described in Section 8.8.2 to mitigate the risk of CSRF such as that described in Section 8.8.2 to mitigate the risk of CSRF
more completely. more completely.
skipping to change at page 30, line 14 skipping to change at page 30, line 14
1. If the domain-attribute is identical to the canonicalized 1. If the domain-attribute is identical to the canonicalized
request-host: request-host:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
Otherwise: Otherwise:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a NOTE: This step prevents "attacker.example" from disrupting the
public registry, such as "com", "co.uk", and "pvt.k12.wy.us". integrity of "site.example" by setting a cookie with a Domain
This step is essential for preventing attacker.com from attribute of "example".
disrupting the integrity of site.example by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an up-
to-date public suffix list, such as the one maintained by the
Mozilla project at http://publicsuffix.org/ [4].
6. If the domain-attribute is non-empty: 6. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If the canonicalized request-host does not domain-match the
domain-attribute: domain-attribute:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
Otherwise: Otherwise:
skipping to change at page 32, line 4 skipping to change at page 31, line 48
attribute-name of "SameSite", set the cookie's same-site-flag to attribute-name of "SameSite", set the cookie's same-site-flag to
the attribute-value of the last attribute in the cookie- the attribute-value of the last attribute in the cookie-
attribute-list with an attribute-name of "SameSite" (i.e. either attribute-list with an attribute-name of "SameSite" (i.e. either
"Strict", "Lax", or "None"). Otherwise, set the cookie's same- "Strict", "Lax", or "None"). Otherwise, set the cookie's same-
site-flag to "None". site-flag to "None".
14. If the cookie's "same-site-flag" is not "None": 14. If the cookie's "same-site-flag" is not "None":
1. If the cookie was received from a "non-HTTP" API, and the 1. If the cookie was received from a "non-HTTP" API, and the
API was called from a context whose "site for cookies" is API was called from a context whose "site for cookies" is
not an exact match for request-uri's host's registered not an exact match for request-uri's host's registrable
domain, then abort these steps and ignore the newly created domain, then abort these steps and ignore the newly created
cookie entirely. cookie entirely.
2. If the cookie was received from a "same-site" request (as 2. If the cookie was received from a "same-site" request (as
defined in Section 5.2), skip the remaining substeps and defined in Section 5.2), skip the remaining substeps and
continue processing the cookie. continue processing the cookie.
3. If the cookie was received from a request which is 3. If the cookie was received from a request which is
navigating a top-level browsing context [HTML] (e.g. if the navigating a top-level browsing context [HTML] (e.g. if the
request's "reserved client" is either "null" or an request's "reserved client" is either "null" or an
skipping to change at page 33, line 44 skipping to change at page 33, line 37
2. Cookies whose secure-only-flag is not set, and which share a 2. Cookies whose secure-only-flag is not set, and which share a
domain field with more than a predetermined number of other domain field with more than a predetermined number of other
cookies. cookies.
3. Cookies that share a domain field with more than a predetermined 3. Cookies that share a domain field with more than a predetermined
number of other cookies. number of other cookies.
4. All cookies. 4. All cookies.
If two cookies have the same removal priority, the user agent MUST If two cookies have the same removal priority, the user agent MUST
evict the cookie with the earliest last-access date first. evict the cookie with the earliest last-access-time first.
When "the current session is over" (as defined by the user agent), When "the current session is over" (as defined by the user agent),
the user agent MUST remove from the cookie store all cookies with the the user agent MUST remove from the cookie store all cookies with the
persistent-flag set to false. persistent-flag set to false.
5.5. The Cookie Header 5.5. The Cookie Header
The user agent includes stored cookies in the Cookie HTTP request The user agent includes stored cookies in the Cookie HTTP request
header. header.
skipping to change at page 43, line 29 skipping to change at page 43, line 13
confuse users unless sites' developers carefully ensure that their confuse users unless sites' developers carefully ensure that their
cookie-based session management systems deal reasonably well with cookie-based session management systems deal reasonably well with
top-level navigations. top-level navigations.
Consider the scenario in which a user reads their email at MegaCorp Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://site.example/". They might expect Inc's webmail provider "https://site.example/". They might expect
that clicking on an emailed link to "https://projects.example/secret/ that clicking on an emailed link to "https://projects.example/secret/
project" would show them the secret project that they're authorized project" would show them the secret project that they're authorized
to see, but if "projects.example" has marked their session cookies as to see, but if "projects.example" has marked their session cookies as
"SameSite", then this cross-site navigation won't send them along "SameSite", then this cross-site navigation won't send them along
with the request. "projects.com" will render a 404 error to avoid with the request. "projects.example" will render a 404 error to avoid
leaking secret information, and the user will be quite confused. leaking secret information, and the user will be quite confused.
Developers can avoid this confusion by adopting a session management Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptually system that relies on not one, but two cookies: one conceptually
granting "read" access, another granting "write" access. The latter granting "read" access, another granting "write" access. The latter
could be marked as "SameSite", and its absence would prompt a could be marked as "SameSite", and its absence would prompt a
reauthentication step before executing any non-idempotent action. reauthentication step before executing any non-idempotent action.
The former could drop the "SameSite" attribute entirely, or choose The former could drop the "SameSite" attribute entirely, or choose
the "Lax" version of enforcement, in order to allow users access to the "Lax" version of enforcement, in order to allow users access to
data via top-level navigation. data via top-level navigation.
skipping to change at page 48, line 21 skipping to change at page 47, line 52
June 2016, <http://unicode.org/reports/tr46/>. June 2016, <http://unicode.org/reports/tr46/>.
10.3. URIs 10.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/6265bis [3] https://github.com/httpwg/http-extensions/labels/6265bis
[4] http://publicsuffix.org/ [4] https://github.com/httpwg/http-extensions/issues/243
[5] https://github.com/httpwg/http-extensions/issues/243 [5] https://github.com/httpwg/http-extensions/issues/246
[6] https://github.com/httpwg/http-extensions/issues/246 [6] https://www.rfc-editor.org/errata_search.php?rfc=6265
[7] https://www.rfc-editor.org/errata_search.php?rfc=6265 [7] https://github.com/httpwg/http-extensions/issues/247
[8] https://github.com/httpwg/http-extensions/issues/247 [8] https://github.com/httpwg/http-extensions/issues/201
[9] https://github.com/httpwg/http-extensions/issues/201 [9] https://github.com/httpwg/http-extensions/issues/204
[10] https://github.com/httpwg/http-extensions/issues/204 [10] https://github.com/httpwg/http-extensions/issues/222
[11] https://github.com/httpwg/http-extensions/issues/222 [11] https://github.com/httpwg/http-extensions/issues/248
[12] https://github.com/httpwg/http-extensions/issues/248 [12] https://github.com/httpwg/http-extensions/issues/295
[13] https://github.com/httpwg/http-extensions/issues/295 [13] https://github.com/httpwg/http-extensions/issues/302
[14] https://github.com/httpwg/http-extensions/issues/302 [14] https://github.com/httpwg/http-extensions/issues/389
[15] https://github.com/httpwg/http-extensions/issues/389 [15] https://github.com/httpwg/http-extensions/issues/199
[16] https://github.com/httpwg/http-extensions/issues/199 [16] https://github.com/httpwg/http-extensions/issues/788
[17] https://github.com/httpwg/http-extensions/issues/788 [17] https://github.com/httpwg/http-extensions/issues/594
[18] https://github.com/httpwg/http-extensions/issues/594 [18] https://github.com/httpwg/http-extensions/issues/159
[19] https://github.com/httpwg/http-extensions/issues/159 [19] https://github.com/httpwg/http-extensions/issues/159
[20] https://github.com/httpwg/http-extensions/issues/159 [20] https://github.com/httpwg/http-extensions/issues/901
[21] https://github.com/httpwg/http-extensions/issues/901 [21] https://github.com/httpwg/http-extensions/pull/1035
[22] https://github.com/httpwg/http-extensions/pull/1038
[23] https://github.com/httpwg/http-extensions/pull/1040
[24] https://github.com/httpwg/http-extensions/pull/1047
Appendix A. Changes Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00 A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes. o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01 A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to o Fixes to formatting caused by mistakes in the initial port to
Markdown: Markdown:
* https://github.com/httpwg/http-extensions/issues/243 [5] * https://github.com/httpwg/http-extensions/issues/243 [4]
* https://github.com/httpwg/http-extensions/issues/246 [6] * https://github.com/httpwg/http-extensions/issues/246 [5]
o Addresses errata 3444 by updating the "path-value" and "extension- o Addresses errata 3444 by updating the "path-value" and "extension-
av" grammar, errata 4148 by updating the "day-of-month", "year", av" grammar, errata 4148 by updating the "day-of-month", "year",
and "time" grammar, and errata 3663 by adding the requested note. and "time" grammar, and errata 3663 by adding the requested note.
https://www.rfc-editor.org/errata_search.php?rfc=6265 [7] https://www.rfc-editor.org/errata_search.php?rfc=6265 [6]
o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations
section: https://github.com/httpwg/http-extensions/issues/247 [8] section: https://github.com/httpwg/http-extensions/issues/247 [7]
o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone],
removing the ability for a non-secure origin to set cookies with a removing the ability for a non-secure origin to set cookies with a
'secure' flag, and to overwrite cookies whose 'secure' flag is 'secure' flag, and to overwrite cookies whose 'secure' flag is
true. true.
o Merged the recommendations from o Merged the recommendations from
[I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and
"__Host-" cookie name prefix processing instructions. "__Host-" cookie name prefix processing instructions.
A.3. draft-ietf-httpbis-rfc6265bis-02 A.3. draft-ietf-httpbis-rfc6265bis-02
o Merged the recommendations from o Merged the recommendations from
[I-D.ietf-httpbis-cookie-same-site], adding support for the [I-D.ietf-httpbis-cookie-same-site], adding support for the
"SameSite" attribute. "SameSite" attribute.
o Closed a number of editorial bugs: o Closed a number of editorial bugs:
* Clarified address bar behavior for SameSite cookies: * Clarified address bar behavior for SameSite cookies:
https://github.com/httpwg/http-extensions/issues/201 [9] https://github.com/httpwg/http-extensions/issues/201 [8]
* Added the word "Cookies" to the document's name: * Added the word "Cookies" to the document's name:
https://github.com/httpwg/http-extensions/issues/204 [10] https://github.com/httpwg/http-extensions/issues/204 [9]
* Clarified that the "__Host-" prefix requires an explicit "Path" * Clarified that the "__Host-" prefix requires an explicit "Path"
attribute: https://github.com/httpwg/http-extensions/issues/222 attribute: https://github.com/httpwg/http-extensions/issues/222
[11] [10]
* Expanded the options for dealing with third-party cookies to * Expanded the options for dealing with third-party cookies to
include a brief mention of partitioning based on first-party: include a brief mention of partitioning based on first-party:
https://github.com/httpwg/http-extensions/issues/248 [12] https://github.com/httpwg/http-extensions/issues/248 [11]
* Noted that double-quotes in cookie values are part of the * Noted that double-quotes in cookie values are part of the
value, and are not stripped: https://github.com/httpwg/http- value, and are not stripped: https://github.com/httpwg/http-
extensions/issues/295 [13] extensions/issues/295 [12]
* Fixed the "site for cookies" algorithm to return something that * Fixed the "site for cookies" algorithm to return something that
makes sense: https://github.com/httpwg/http-extensions/ makes sense: https://github.com/httpwg/http-extensions/
issues/302 [14] issues/302 [13]
A.4. draft-ietf-httpbis-rfc6265bis-03 A.4. draft-ietf-httpbis-rfc6265bis-03
o Clarified handling of invalid SameSite values: o Clarified handling of invalid SameSite values:
https://github.com/httpwg/http-extensions/issues/389 [15] https://github.com/httpwg/http-extensions/issues/389 [14]
o Reflect widespread implementation practice of including a cookie's o Reflect widespread implementation practice of including a cookie's
"host-only-flag" when calculating its uniqueness: "host-only-flag" when calculating its uniqueness:
https://github.com/httpwg/http-extensions/issues/199 [16] https://github.com/httpwg/http-extensions/issues/199 [15]
o Introduced an explicit "None" value for the SameSite attribute: o Introduced an explicit "None" value for the SameSite attribute:
https://github.com/httpwg/http-extensions/issues/788 [17] https://github.com/httpwg/http-extensions/issues/788 [16]
A.5. draft-ietf-httpbis-rfc6265bis-04 A.5. draft-ietf-httpbis-rfc6265bis-04
o Allow "SameSite" cookies to be set for all top-level navigations. o Allow "SameSite" cookies to be set for all top-level navigations.
https://github.com/httpwg/http-extensions/issues/594 [18] https://github.com/httpwg/http-extensions/issues/594 [17]
o Treat "Set-Cookie: token" as creating the cookie "("", "token")": o Treat "Set-Cookie: token" as creating the cookie "("", "token")":
https://github.com/httpwg/http-extensions/issues/159 [19] https://github.com/httpwg/http-extensions/issues/159 [18]
o Reject cookies with neither name nor value (e.g. "Set-Cookie: =" o Reject cookies with neither name nor value (e.g. "Set-Cookie: ="
and "Set-Cookie:": https://github.com/httpwg/http-extensions/ and "Set-Cookie:": https://github.com/httpwg/http-extensions/
issues/159 [20] issues/159 [19]
o Clarified behavior of multiple "SameSite" attributes in a cookie o Clarified behavior of multiple "SameSite" attributes in a cookie
string: https://github.com/httpwg/http-extensions/issues/901 [21] string: https://github.com/httpwg/http-extensions/issues/901 [20]
A.6. draft-ietf-httpbis-rfc6265bis-05
o Typos and editorial fixes: https://github.com/httpwg/http-
extensions/pull/1035 [21], https://github.com/httpwg/http-
extensions/pull/1038 [22], https://github.com/httpwg/http-
extensions/pull/1040 [23], https://github.com/httpwg/http-
extensions/pull/1047 [24].
Acknowledgements Acknowledgements
RFC 6265 was written by Adam Barth. This document is a minor update RFC 6265 was written by Adam Barth. This document is a minor update
of RFC 6265, adding small features, and aligning the specification of RFC 6265, adding small features, and aligning the specification
with the reality of today's deployments. Here, we're standing upon with the reality of today's deployments. Here, we're standing upon
the shoulders of a giant since the majority of the text is still the shoulders of a giant since the majority of the text is still
Adam's. Adam's.
Authors' Addresses Authors' Addresses
 End of changes. 65 change blocks. 
91 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/