| I think the IETF should look at three issues:
1. HTTP Re-direct flows in support of workflows (eg MFA sign-on flows) - HTTP redirect is the single most complex part of OAuth2 and drove a lot of the OAuth2 Threat Model and the subsequent drafts such as PKCE. Right now, OAuth takes the blame because of its extensive recommendations and corrections (e.g. PKCE) to handle requirements not unique to OAuth2.
2. Authentication of client applications - enabling the ability to identify a returning client or provide an asserted identity still needs to be solved. Token Binding seemed like the solution, but that’s stalled. Now what? OAuth Dynamic registration is an example of how complex things can get without being able to identify a returning entity positively. Can we make this as easy as TLS has been for authenticating servers?
3. YETA - OAuth has spawned a number of parallel efforts (IoT, OIDC, ... and now GNAP). Are these new profiles making generational improvements to replace OAuth2 or are they just adding more options and complexity to the mix? I point to ongoing developer confusion on the purpose and differences between OIDC and OAuth2. It is very clear to me, but why not to developers at large? Could it be they don’t want to care? Developers are still asking “why can’t I just use basic auth”? There is a debate that specialization (by eliminating options) leads to simplicity and focus. But when specialization drives YETA, it is really just more complexity. Again, this suggests options 1 and 2 need to be looked at before OAuth2 and its flavors can improve. Is it time to work on bringing all of these together on top of a new HTTP workflow framework?
Cheers,
Vittorio, I feel you are conflating OIDC with OAuth2. In delegation
workflows, the AS/RS can be any company and the clients are
approved registered clients. I use OAuth2 for many of my own
consumer needs and there is an even distribution of use among many
services. OAuth2 protects me. I no longer have to hand out my
twitter credentials just because my conference website wants
limited access to my twitter account. I can now give my conference
website limited delagated access to my twitter account and cancel
that relationship any time. For years I was forced to give up my
banking credentials to services like Mint and that is no longer
the case due to the OAuth2 financial extension (FAPI).
While OIDC is certainly centralizing identity to a few providers,
a real problem, OAuth2 when used for delegation purposes does not
have that same inherent risk. Respectfully, - Jim Manico
On 3/1/21 9:59 AM, Vittorio Bertola
wrote:
How does OAuth harm privacy?
I think you are analyzing the matter at a different level.
If you start from a situation in which
everyone is managing their own online identity and credentials,
and end up in a situation in which a set of very few big
companies (essentially Google, Apple and Facebook) are supplying
and managing everyone's online credentials and logins, then [the
deployment of] OAuth[-based public identity systems] is harming
privacy.
Centralization is an inherent privacy
risk. If you securely and privately deliver your personal
information to parties that can monetize, track and aggregate it
at scale, then you are losing privacy.
--
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________ OAuth mailing list OAuth@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/oauth
|
