[OAUTH-WG] Re: OAuth for Browser-Based Apps BCP

[Deb Cooley <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>>
>>
>> On Fri, Jun 26, 2026 at 3:19 AM Neil Madden <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> > On 26 Jun 2026, at 00:50, Aaron Parecki <aaron=
>>> [e-mail]> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>