Hi Pedram,
Thanks for confirming that the scenario is as I was trying to understand
it. I don't think it's universal that all clients will give transitive
access from the user to the accessed resource, though it's certainly
common; the lack of exposition on that point is what I had been stumbling
Hi Ben,
The attacker uses the (honest) client shown in Figure 4 as a regular
user. For example, the client might provide access to a cloud storage
via its website, i.e., by using the clients' website, a user can access
her files stored at the resource server.
I'll try to clarify the attack w
Hi Pedram,
On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
>
> Also, for this or the next version of this document, the Cuckoo's Token
> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should
> be addressed. We also discussed this issue extensively at the last O
Hi Guido,
thanks for the feedback! I incorporated most of it into the next version.
Some comments:
Am 22.11.19 um 18:00 schrieb Guido Schmitz:
> * Section 3.1, Third Paragraph, Section 4.7, and other places throughout
> the document: (Please excuse that the following might be a bit
> nitpicking
Hi,
All of my comments on oauth-security-topics-13 are
remarks/questions/suggestions for clarification in the document, i.e., I
do not have any fundamental objections. Overall, the draft is, in my
opinion, in good shape to be published and as already discussed, open
points can be updated later. I
Dear all,
I have a few comments about the leakage of access tokens and the
underlying assumptions:
Section 2, A5 should be clarified:
"a resource server can be compromised by an attacker": Is the assumption
that the attacker cannot get access to the resources stored at the
compromised RS (o
