Picking in on one item:
>> Section 6.1.3.2
>> “
>> • The BFF SHOULD enable the SameSite=Strict flag for its cookies
>> • The BFF SHOULD set its cookie path to /
>> • The BFF SHOULD NOT set the Domain attribute for cookies
>> • The BFF SHOULD start the name of its cookies with the __Host- prefix
>> ([CookiePrefixes])
>> ”
>> The above statements use “SHOULD”, which implies that in some cases these
>> can be ignored. Section 6.1.3.3.1 then elaborates on the “sameSite” flag.
>> Should there be some text to elaborate on the others?
>> I added a sentence to clarify this a bit. In my opinion, these can
>> definitely all be MUSTs, but that may conflict with certain corner cases or
>> implementation strategies. We can continue this discussion if the current
>> fix is not sufficient.
>>
> I guess my question was: are there valid reasons for an implementer to
> deviate from these security guidelines?
> If the answer is no, then why not change all of them to MUST?
> After all, the goal of this document is to encourage people to do the right
> thing.
>
Yes, the web is messy enough to guarantee that some people will not be able to
use this exact configuration. IMO, the SHOULD will help people who want to do
the right thing, while it also allows people to deviate where needed. It should
function as a clue to think about why they would not do this, but maybe I’m too
optimistic here :)
Philippe
—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
