Hi Bruno,
thanks for your insights.
The recommendation is not only based on security considerations but just
utility. As soon as one wants to integrate federated login or multi factor
authentication, ROPG reaches its limits.
Moreover, how do those teams implement user registration and user ac
No - please get rid of it.
———
Dominick Baier
On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com) wrote:
Hey List
(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron,
Torsten, and I are working on)
Given the points Aaron brought up in
https://mailarchive.ietf
Hi Guys,
I really understand the security and motivations behind ROPC and I'm not
against the decision it is deprecated. Actually I see many devs and teams
using ROPC to deliver a better UI experience in Mobile apps and easy
integration.
They try to follow specs of RFC 8252 and AppAuth isn't easy
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Pushed Authorization Requests
Authors : Torsten Lodderstedt
Br
I would also seriously look at the original motivation behind ROPC: I know
it has been deployed and is used in quite a lot of places but I have never
actually come across a use case where it is used for migration purposes and
the migration is actually executed (I know that is statistically not a ve
Agreed. Plus, the Security BCP is already effectively acting as a grace
period since it currently says the password grant MUST NOT be used, so in
the OAuth 2.0 world that's already a pretty strong signal.
Aaron
On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote:
> There is no need for a grac
I do recall password flow was only in 6749 to facilitate transition to oauth..
Maybe it is reasonable to consider ending it now.
Phil
> On Feb 18, 2020, at 1:15 PM, Justin Richer wrote:
>
> There is no need for a grace period. People using OAuth 2.0 can still do
> OAuth 2.0. People using OAu
There is no need for a grace period. People using OAuth 2.0 can still do OAuth
2.0. People using OAuth 2.1 will do OAuth 2.1.
— Justin
> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin
> wrote:
>
> I would suggest a SHOULD NOT instead of MUST, there are still sites using
> this and a grace pe
The security topics says MUST. If you want to change that, then that is a
different discussion. :)
In the OAuth 2.1 document, it would just not be included. Applications can
continue to be OAuth 2.0 compliant.
BUT ... if there are valid, new use cases. Please describe them! Perhaps it
should not
I would suggest a SHOULD NOT instead of MUST, there are still sites using this
and a grace period should be provided before a MUST is pushed out as there are
valid use cases out there still.
From: OAuth On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: oauth@ietf.org
Subject
Hey List
(Once again using the OAuth 2.1 name as a placeholder for the doc that
Aaron, Torsten, and I are working on)
In the security topics doc
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
The password grant MUST not be used.
Some background for those interested
Hey List
(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron,
Torsten, and I are working on)
Given the points Aaron brought up in
https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU
Does anyone have concerns with dropping the implicit flow from the OAuth
2
12 matches
Mail list logo
