It sounds like there is general agreement on this approach. The change is sitting in a PR right now:
https://github.com/oauth-wg/oauth-browser-based-apps/pull/112/changes I will need advice from the chairs or AD on how to proceed here. I am hoping to resolve this without working group time in Vienna since the agenda is going to be extremely full. Aaron On Sat, Jun 27, 2026 at 12:28 AM Philippe De Ryck < [email protected]> wrote: > Enforcing the __Host-Http- prefix not only affects JS readability, but > also writeability from JS (e.g., an attacker writing a cookie through an > XSS attack vector). That’s why the spec explicitly states > > This helps developers and server operators to know that the cookie was set > using a Set-Cookie header > > > These prefixes are minor tweaks to the security model of the web, but they > do offer benefits and exist for a reason. These should become the default > for all cookies used, but each time I cover this topic in training, almost > no-one knows about cookie prefixes. It would be a bit of a missed > opportunity to release a browser-oriented spec without recommending the > best practices currently available, hence my request to update. > > Looking forward to finalizing the Browser-based apps BCP > > Philippe > > — > *Pragmatic Web Security* > *Security for developers* > https://pragmaticwebsecurity.com > > On 27 Jun 2026, at 04:03, Dhruv Agnihotri <[email protected]> wrote: > > +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] > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
