Code change:
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). </del> <ins> URI must denote a "secure" connection (as defined by the user agent). </ins> <del> 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> <ins> 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".

Related discussion:
text: (I believe this is intended by latest draft, but as NAME pointed this might need some changes to the Storage Model section) NAME Could you help clarify more about "2 min Lax+POST mitigation"? I see it mentioned above but it would be great to discuss how the mitigation should behave exactly.
URL is the spec language around the behavior. As a quick refresher: the goal is to allow unsafe http methods (commonly POST) to attach cookies that do not specify a attribute but are being treat as "lax by default". This behavior is intended for newly created cookies and so has a lifetime limit of up to 2 minutes. Let me know if you have any more specific questions.
We (NAME NAME NAME and I) discussed this at TPAC and came to the following suggestion: We think that browsers have to apply a compatibility measure here, and it could be including cookies on cross-site redirects if they’re younger than, for example, 2 minutes. We’ll collect metrics to get a better understanding of what that number should be. We will update "Lax-Allowing-Unsafe" in the spec to document that behavior, which would make Chromium compliant to that and Firefox could (AFAIU) ship a compliant version as well. We’ll continue to recommend "Lax-Allowing-Unsafe" as the default behavior in the spec. We’ll note that this is a compatibility mechanism that browsers may support or not support at their own discretion. It's not a behavior sites should opt into.
I believe the "same-site redirect chain consideration" change should be removed from RFC6265bis, with the intention of adding it back to RFC6265Tris. RFC6265bis contains a number of improvements over RFC6265 that are being stalled due to UAs being unable to implement "same-site redirect chain consideration" in a web compatible way. My efforts examining metrics collected by Chrome haven't yet offered much insight into how this issue could be solved and I have no idea how much longer it could take. Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections. But publishing RFC6265bis as a new spec will have a number of benefits, including security/privacy benefits for the web's users.
This seems like a reasonable, pragmatic step to me.