A few comments and changes that I think should be made or would read more
clearly.
3.1 Paragraph #2
Should probably read either of the following
Clients SHOULD avoid forwarding the user's browser to a URI obtained
from a query parameter since such a function could be utilized to
exfiltrate
You are welcome. I'm always happy to be able to help with a major
contribution such as this one :)
I did read through the draft for WGLC back in September though and that was
the only issue that jumped out at me.
On Wed, Nov 6, 2019 at 6:15 PM William Denniss wrote:
>
> On Wed, Sep 25, 2019 at
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
