Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Forgot one more thing In 7.1 Browser-based apps MUST use the OAuth 2.0 "state" parameter to protect themselves against Cross-Site Request Forgery and authorization code swap attacks and MUST use a unique value for each authorization request, and MUST verify the returned state in the a

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Technically it could be optional, but it means that a CSRF attempt will only be detected by the AS not by the client. If we consider the possibility of a malicious AS, then this could allow Login CSRF attacks against the client. The client would also have to be sure that the AS actually implemen

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden : > Technically it could be optional, but it means that a CSRF attempt will only > be detected by the AS not by the client. If we consider the possibility of a > malicious AS, then this could al

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Yes it would. ——— Dominick On 23. July 2019 at 10:08:43, Filip Skokan (panva...@gmail.com) wrote: Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden : Technically it could be optional, but it means that a CSRF attempt will only be detected by t

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Not sure I follow - the current OAuth security topics BCP allows for using either state or PKCE for detecting CSRF (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..7.1 ), with some caveats

Re: [OAUTH-WG] Transaction Authorization

If we follow the principle of least authority then a token should be scoped as narrowly as possible to a particular resource server/resource/time period/transaction. The security topics BCP has already gone quite far down this path in its recommendations: https://tools.ietf.org/html/draft-ietf-

Re: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

Thanks Brian, I committed a fix for this. -Daniel Am 22.07.19 um 20:36 schrieb Brian Campbell: > The description of I-D.ietf-oauth-mtls in > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8.1.2 >

[OAUTH-WG] Implicit grant and sender constrained token/JPOP/DPOP

A while ago, when implicit was almost entirely banned in the Security BCP, I raised voice that the ban should be constrained and the text was modified accordingly. At the time, I probably did not express myself well enough so here is a bit of explanation on what I was thinking about the sender con

Re: [OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

One more thing I just noticed is that RFC8418 is used as a reference in a few places that I suspect should be RFC8414. https://tools.ietf.org/html/rfc8418 : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) https://tool

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt wrote: > > 2) Regarding architectures: I think this BCP should focus on > recommendations for securely implementing OAuth in the different potential > architecture. I don’t think we should get into the business of recommending > and assessing ot

[OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

Hi Roman, the latest revision -05 should address all points you raised. https://www.ietf.org/id/draft-ietf-oauth-jwt-introspection-response-05.txt kind regards, Torsten. > On 23. Jul 2019, at 02:56, Roman Danyliw wrote: > > Hi Torsten! > > Separately from the below, idnits is troubled by

[OAUTH-WG] IETF105 Side meeting: PKCE Chosen Challenge attack and potential mitigations

Hi all, Since there was interest to discuss the PKCE Chosen Challenge attack and potential mitigations like IVAR in more detail, I reserved the room *"Centre Ville" at 8:30 am on Thursday* for a side meeting on this topic. Slides describing the attack: https://datatracker.ietf.org/meeting/105/mat

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

Hi Torsten! Thank you for this update. It does address my key issues. With the IETF LC feedback can you please address this idnit introduced in this update: ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Thanks, Roman > -Original Message- > From: Torsten Lodderst

[OAUTH-WG] Dinner tonight (Tuesday)?

Anyone not going to the social that wants to get dinner? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-jwt-introspection-response-03

> Am 24.07.2019 um 00:02 schrieb Roman Danyliw : > > With the IETF LC feedback can you please address this idnit introduced in > this update: sure smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://ww

[OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : Reciprocal OAuth Author : Dick Hardt Filename: draft-ietf-oauth-reciprocal-03.txt

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> On Jul 23, 2019, at 12:47 PM, Brian Campbell > wrote: > > > > On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt > wrote: > > 2) Regarding architectures: I think this BCP should focus on recommendations > for securely implementing OAuth in the different