Original text:
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del>  If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".

Reviewer comments:
Rephrases the requirements for the attribute to be slightly broader in order to support . Currently the requirements specifically ask for a secure protocol, with this change they'll ask for a secure connection (as defined by the user agent). This allows UAs to support cookie access on http://localhost
No WPT that I can see. According to , Firefox fully supports localhost, Chrome supports but not cookie prefixes, and Safari doesn't have support but does have an open bug.
Got it, thanks. If you're taking care of Chromium, and WebKit has an open bug, landing this seems reasonable. Thanks!
We are reporting inconsistent browser behavior regarding cookies and and prefixed cookies on . delegates the decision of what is a "secure protocol" to the user agent when describing how to handle cookies with the attribute. The affects both cookies with the attribute and cookies with name prefixes ( and ). rfc6265bis-12 states the following (): According to our tests: Firefox allows cookies to be set/sent on , as well as and prefixed cookies. Chrome also allows cookies to be set/sent with the attribute. However, and cookies are not allowed. Safari does not allow cookies to be set/sent, and consequently, and cookies are also discarded since they require that the cookie's be set to true via the cookie attribute. The table below summarises browser behavior when setting cookies on , localhost subdomains, and . We noticed these inconsistencies after interacting with developers of Web frameworks while discussing cookie integrity issues. Allowing cookies with the attribute and cookie name prefixes to be used on , would enable adopters of Web frameworks to test their applications locally, removing the burden of setting up HTTPS locally to use these security features. As shown in the table above, Firefox fully supports this behavior, while Chrome's support is still partial. Following , Firefox moved from a "secure protocol" check when handling cookies, to using the definition of specification, where is considered "Potentially Trustworthy". The states that: >An environment is a secure context if the following algorithm returns true: Chrome made the same decision following , and support for and prefixed cookies on has been deemed "in scope" (). Safari is aware of this inconsistency, but there is still no decision regarding changing their behavior (, , ). As the cookie specification does not clearly define the behavior on localhost, we could consider reusing the notion of from the Secure Context specification, instead of suggesting a user-agent-dependent "secure protocol" check on the scheme of the request-URI, in point 13 of . Best regards
I think it's reasonable to modify the phrasing to include potentially trustworthy origins.
This is a good change, thanks. I don't think we have WPT in place for this (and I'm not entirely sure that we can?), but have you looked into the support for this change across browser engines? I'm generally in favor of landing it as long as it's reflecting (near) reality.

Revised text:
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's  <ins> URI must denote a "secure" connection (as defined by the user agent). NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".