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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/