Hi Vittorio,
Hi all,
thanks for the discussion here! We'll add in the security considerations the
following clarification:
“As this specification provides a mechanism for the RS to trigger user
interaction, it’s important for clients and AS to consider that a malicious RS
might abuse of th
Hi all,
thanks for the discussion here! We'll add in the security considerations
the following clarification:
“As this specification provides a mechanism for the RS to trigger user
interaction, it’s important for clients and AS to consider that a malicious
RS might abuse of that feature”
Valery,
Hi Robert,
thanks for your comments!
Some of the ideas you mention here were also touched upon during the AD
review w Roman, the exchange we had might provide some context
https://mailarchive.ietf.org/arch/msg/oauth/PBDCtVB7vtou5Dlz6nPJxX_5Yyo/
but more succinctly:
- "step down". One of the key re
Hi all,
I’d like to pitch the idea of changing the abstract OAuth description to
incorporate how OAuth is used in many B2E applications.
In my view, OAuth 2.1 is a great opportunity to do so, without the need to make
any changes in the core protocol itself, so nothing gets ‘broken’.
The 2.1 RFC
Reviewer: Robert Sparks
Review result: Ready with Issues
Summary: essentially ready but with issues to consider before being published
as a proposed standard RFC.
Issues:
I expected to find some discussion of considerations of avoiding "step down"
given the intuitive appeal to "step up". Can the
> Surely "rogue" resource servers already have a lot of ways they can annoy
> their own users? Is this a realistic threat?
Yes, this is a realistic threat, and I'm aware of at least one example of it
actually being used (successfully!) to penetrate a corporate network.
On Mar 2, 2023, at 07:07
Hi Neil,
Surely "rogue" resource servers already have a lot of ways they can annoy their
own users?
I agree.
Is this a realistic threat?
I don’t know. Probably not. But I see that this protocol adds one more
possibility for “rogue” resource servers t
Surely "rogue" resource servers already have a lot of ways they can annoy their
own users? Is this a realistic threat?
-- Neil
> On 2 Mar 2023, at 08:23, Valery Smyslov wrote:
>
> Thank you for pointing to the deployment consideration section, I re-read it
> :-)
> This section is mostly conce
Thank you for pointing to the deployment consideration section, I re-read it :-)
This section is mostly concerned with accidental bad used experience
caused by incompatible policies. My point is slightly different.
My point is that since this extension adds the possibility of an additional
i
Thanks for clarifying, I was indeed addressing the comment using DoS in its
canonical meaning.
The possibility of bad user experience is indeed present, and it is more
general than just freshness: we do tackle that explicitly in the
deployment considerations section. Did you have a chance to read i
10 matches
Mail list logo
