+1 to publishing. The "for example" softening is the right call. On Neil's question, I read the new prefix as adding a property, though a narrow one, and the "why did HTTPbis add these" question is answered by design rather than by attack.
The layered-cookies draft is structured as orthogonal, composable prefix primitives: `__Host-` enforces origin scoping (Secure + Path=/ + no Domain), `__Http-` enforces non-JS-readability (Secure + HttpOnly), and `__Host-Http-` composes both. Over the existing `__Host-` plus the BCP's `MUST HttpOnly`, the property `__Host-Http-` adds is that HttpOnly enforcement moves from server-side policy to user-agent rejection — layered-cookies §4.1.3.4 plus the cookie filtering algorithm has the UA drop a `__Host-Http-`-named cookie that arrives without HttpOnly. For a spec-compliant deployment this changes nothing; for an operator regression (misconfigured framework, alternate session code path, a downgraded middleware that silently drops the flag) it's a UA-side catch in browsers that have shipped the prefix. So no new attack class against the BCP-conformant baseline, but a defense-in-depth layer for the case the MUST is unintentionally violated. On that basis the example framing reads right: worth pointing at as the direction of travel, not worth making the BCP's binding analysis depend on. (I covered the BFF section of -26 in an *InfoQ* piece earlier this year, "*The DPoP Storage Paradox* <https://www.infoq.com/articles/dpop-key-storage-unsolved-problem/>", happy to dig into specifics on or off list if useful.) Dhruv Agnihotri [email protected] On Fri, Jun 26, 2026 at 3:19 AM Neil Madden <[email protected]> wrote: > > > > On 26 Jun 2026, at 00:50, Aaron Parecki <aaron= > [email protected]> wrote: > > > > Hi all, > > > > As you probably know, the "OAuth for Browser-Based Apps BCP" document > has been stuck in the editor's queue for almost a year waiting on the > publication of RFC6265bis. In the meantime, the HTTPbis working group has > revised the recommendation in RFC6265bis that we reference, changing the > recommendation from prefixing cookies with "__Host-" to "__Host-Http-" in a > new document draft-ietf-httpbis-layered-cookies. > > From what I can see, they've not changed it, they've introduced another > set of prefixes. The __Host- prefix still exists, it just doesn't require > the HttpOnly flag on cookies that are set. Given that the BCP already says > HttpOnly is a MUST, I'm not sure what this adds? > > Does anyone know why the HTTPBis WG added these new prefixes? The old ones > address known concrete security gaps, but I don't see an attack that this > new prefix prevents. > > -- Neil > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
