Thanks Deb, I just merged the PR and published a new version.
Aaron On Mon, Jul 6, 2026 at 12:56 PM Deb Cooley <[email protected]> wrote: > If the working group agrees (It looked good to me?), I'd push out a new > version. That will get the attention of the RFC Editor who will tell us > what needs to happen next. > > The ID submission system closes today... > > Deb > > On Wed, Jul 1, 2026 at 7:04 PM Aaron Parecki <[email protected]> wrote: > >> 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]
