pient, please notify the sender and delete
this e-mail.
-Original Message-
From: OAuth On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 6, 2019 5:27 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
Hi all,
this is a working gr
> Am 19.11.2019 um 13:39 schrieb Vineet Banga :
>
> Let me restate my original question. I agree with the usage of state for CSRF
> protection, but it can also be used to capture the application state (as
> specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if there is
> any re
> On 17. Nov 2019, at 05:42, Vineet Banga wrote:
>
>
> On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt
> wrote:
>
> >> On 16. Nov 2019, at 02:07, Vineet Banga
> >> wrote:
> >>
> >> Just one comment/question at the moment:
> > >3.1.1 - Is there any recommendation around leveraging st
> On 16. Nov 2019, at 02:07, Vineet Banga
> wrote:
>
> Just one comment/question at the moment:
> 3.1.1 - Is there any recommendation around leveraging state vs using multiple
> URIs (with exact match) to remember the application state of the client? I
> have seen exploding list of registere
Daniel,
I have the feeling that this attack aims at breaking a security
property that OAuth does not claim to fulfill (and that nobody expects
OAuth to fulfill):
The first comment sent to the list was to ask whether the list of
attacks was complete. IMO, the list should not be limited to the
On Nov 10, 2019, at 2:02 PM, Lee McGovern wrote:
>
>
> 3.1 - "Clients MUST memorize which authorization server they sent an
> authorization request to" - is memorize the best synonym here, perhaps store
> or retain is more aligned with computational language?
Store, retain, persist are all co
ts
of the access token to be aligned
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-02
--
Date: Wed, 6 Nov 2019 08:26:49 +
From: Hannes Tschofenig
To: "oauth@ietf.org"
Subject: [OAUTH-WG] WGLC for
On Nov 9, 2019, at 1:08 PM, Torsten Lodderstedt wrote:
> But what does „same client“ mean? Is it the client_id? Sounds reasonable for
> a web app, but would also mean instances of the same native app residing on
> different devices could share the consent. That’s great from a convenience
> pers
Hi Daniel,
> Am 09.11.2019 um 18:44 schrieb Daniel Roesler
> :
>
> I realize that it's open to the authorization server to issue
> authorization codes how they see fit. It just strikes me as odd that
> there's not a lot of guidance around when transparent redirects are
> safe, when user interact
Howdy DW,
Thanks very much for your response! It's totally understandable that
the authorization server should ask for re-confirm if the
refresh_token is no longer valid, and it's also understandable that if
you're using implicit flow with only an access_token that you don't
need to ask for re-con
Hello Daniel!
> 1. The client makes an ajax HEAD request to the OAuth authorization
> endpoint, which will silently create the authorization grant (this was
> the security exploit that was patched).
> Anyway, I'm trying to find guidance on transparent redirects for
> authorization code grants. Th
I have the feeling that this attack aims at breaking a security property
that OAuth does not claim to fulfill (and that nobody expects OAuth to
fulfill):
"Given two colluding clients A and B, where A has obtained an access
token T, B cannot use T to access protected resources."
(analogously for tw
screenshot...
Hans.
On Fri, Nov 8, 2019 at 2:13 PM Denis wrote:
> Hello Hans,
>
> You wrote:
>
> one client can always share the protected data with another client once
> retrieved, regardless of pop or secure elements
>
> No, there exist means that prevent a client to share the protected data
Hello Hans,
You wrote:
one client can always share the protected data with another client
once retrieved, regardless of pop or secure elements
No, there exist means that prevent a client to share the protected data
with another client , simply because the client cannot access to it.
The prot
Howdy,
In the "3.1 Protecting Redirect-Based Flows" > "3.1.1. Authorization
Code Grant" section, is there guidance on when it is appropriate (if
ever) to automatically generate a new authorization code and redirect
back to the client?
A recent exploit[1] on Github's OAuth implementation was pract
one client can always share the protected data with another client once
retrieved, regardless of pop or secure elements
Hans.
On Fri, Nov 8, 2019 at 8:38 AM Denis wrote:
> Daniel,
>
> No. It is not a correct summary. One client can allow another client to
> get an access token that belongs to i
Daniel,
No. It is not a correct summary. One client can allow another client to
get an access token that belongs to it.
The key point is that a software only solution can't prevent this
collaborative attack and since, at this time,
the OAuth WG is not considering the use of secure elements, the
Hi Denis,
Am 07.11.19 um 09:16 schrieb Denis:
>
> *Whatever kind of cryptographic is being used, when two users
> collaborate, a software-only solution will be unable to prevent the
> transmission *
> * of an attribute of a user that possess it to another user that
> does not possess
Hello Jared,
You raised the following question :
*
**Should other possible threats and vulnerabilities be included?
Meaning, is the list the definitive known list?*
This list is certainly not a "definitive /known /list" since there
exists an additional /known /threat that has been advertised
1. Normative MUST/REQUIRED is fine in a BCP.
2. This is not the definitive list, but instead the best list of things that we
have at this time. There will be more attacks, and more mitigations for those
attacks.
— Justin
> On Nov 6, 2019, at 3:16 PM, Jared Jennings wrote:
>
> Hi,
>
> This
Hi,
This is my first time reviewing a document or responding to the group. So,
with that introduction feel free to guide me along the way.
Reading through the document, I had a few high-level questions first. I
will have more detailed comments later, once I know I'm on the right track
and I assum
Hi all,
this is a working group last call for "OAuth 2.0 Security Best Current
Practice".
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
Please send you comments to the OAuth mailing list by Nov. 27, 2019.
(We use a three week WGLC because of the IETF meet
22 matches
Mail list logo
