Answers inline to add the proper nuance.
> Would you not agree that a "good" CSP config is a good line of defense
> against XSS attacks?
A good CSP policy can indeed help to stop the exploitation of an XSS
vulnerability, should one exist in the application. I do not agree with the
wording “a
I read through the draft while doing some prep for the meetings this week
(which I'm attending remotely). While I have reservations about the idea of
the WG taking on and endorsing the work, I did have some
comments/suggestions on the general content of the draft that hopefully
will be useful nonet
Would you not agree that a "good" CSP config is a good line of defense
against XSS attacks?
I agree that the OAuth BCP should not provide details on CSP config. I do
think we should call out having a considered CSP config is a best practice.
I differentiate between headers and cookies and SQL inj
Hi Neil. Thank you for suggesting text! I agree we’re closing in on some
actionable changes here (I've added some issues in the github repo to keep
track FWIW) and we'll work to incorporate the text you've suggested.
I do see how the text you've cited in 11.8 11.6, and 8.3 (there is no 8.4
so maki
I went back to the Security BCP and combed through the fine details, and there
is indeed some guidance on CSP. But your initial remark that this is "vague" is
definitely true, and this section is actually a good illustration of what I was
trying to say. Let me unpack the details a bit …
In sect
> On 6 Nov 2023, at 16:43, Watson Ladd wrote:
>
> On Mon, Nov 6, 2023 at 5:46 AM Neil Madden wrote:
>
>>
>> How about the following:
>>
>> —
>> An Issuer MUST NOT allow any security-critical claim to be selectively
>> disclosable. The exact list of “security-critical” claims will depend on
That's a surprising response Philippe. The BCP already has
Content-Security-Policy and Referrer-Policy headers recommendations. The
core of my feedback is to add Cookie and Header best practices to Section
2, and point to one or more living documents.
On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryc
While I understand the idea of pointing to additional security resources, I’m
not sure if it is the role of the security BCP (or other specs) to take on the
responsibility to address these issues. In my point of view, the security BCP
should focus on OAuth aspects, and discuss security topics th
On Mon, Nov 6, 2023 at 5:46 AM Neil Madden wrote:
>
> How about the following:
>
> —
> An Issuer MUST NOT allow any security-critical claim to be selectively
> disclosable. The exact list of “security-critical” claims will depend on the
> application, and SHOULD be listed by any application-spe
+1 to referring to calling out that cookies / headers should follow best
security practice, and pointing to living documents
On Mon, Nov 6, 2023 at 6:21 AM Giuseppe De Marco
wrote:
> Hi,
>
> everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
> different projects and orgs, I have
Hi,
everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
different projects and orgs, I have included secured web cookie in
the recipe.
For the implementation profile of OpenID4VP I did the same, where the
secured and httponly cookie is used an in particular as a basic security
requi
Although I think we could add some basic advice, the list of security headers
to use is still evolving. For example, there were several headers added after
Spectre to limit cross-site interactions. And then there’s things like the
“X-XSS-Protection” header, which was best practice to add to resp
Although I think we could add some basic advice, the list of security headers
to use is still evolving. For example, there were several headers added after
Spectre to limit cross-site interactions. And then there’s things like the
“X-XSS-Protection” header, which was best practice to add to resp
Hi Brian,
Apologies for the late reply. I *think* we’re closing in on agreement here.
Comments and some wording suggestions inline below.
> On 27 Oct 2023, at 00:26, Brian Campbell wrote:
>
> Thanks Neil! Appreciate the productive discussion. Some more responses below
> (while also attemptin
From: Kai Lehmann
Date: Monday, 6. November 2023 at 07:48
To: "oauth@ietf.org"
Subject: OAuth browser based apps with first-party same-domain apps
Hi,
I’ve been reading through the recent update of the draft for using OAuth in
browser based apps and highly appreciate the excellent work.
The
15 matches
Mail list logo
