+1, Antonio and John convinced me that this is not limited to a
registration curation problem although that is where the problems starts
as Phil points out (and as much as I'd like it to stay there).
There are and will be consumer OPs (like Google) that have no means to
do whitelisting yet hav
Hi
I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then does it imply
there's serious a weakness present somewhere else, in the
registration process for ex
hi Sergey
On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>> wrote:
Hi
I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redirect URIs, intentionally or unintentionally, then doe
hi Phil.
On Sep 15, 2014, at 11:21 PM, Phil Hunt
mailto:phil.h...@oracle.com>> wrote:
So, let’s say you have a client that has “obtained” a client Id from a legit
registered client. How does the malicious client exploit the previously
registered URL if the server only redirects to that URL?
T
Hi John,
agree that there are at two different things (as you pointed out below) where
we could spend some word and provide some advice.
To summarize:
- one is the 'open redirect’ issue (net of semantic :), pointed by me, where
nothing is leaked
- one is the leakage, pointed by John
Those t
Hi Antonio
On 16/09/14 09:52, Antonio Sanso wrote:
hi Sergey
On Sep 16, 2014, at 10:44 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:
Hi
I wonder, when we have a situation where any client, the malicious
clients, or good clients, all of them can easily register and provide
bad redi
I'll reiterate what convinced me if it helps.
The danger was a matter of expectations. In Antonio's scenario, the
user is more likely to be expecting a login screen and thus more likely
to be fooled by a login-screen spoof. Antonio's suggested changes don't
break any compatibility either, it
I will re-iterate here my strong preference that an "unsecured" or
"plaintext" JWS object be syntactically distinct from a real JWS object.
E.g. by having two dot-separated components instead of three.
Beyond that, seems like just shuffling deck chairs.
On Mon, Sep 8, 2014 at 12:10 PM, Brian Camp
