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, Phil Hunt @independentid phil.h...@independentid.com > On Mar 1, 2021, at 8:32 AM, Jim Manico <j...@manicode.com> wrote: > > 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: >> >>> Il 01/03/2021 15:13 Jim Manico <j...@manicode.com> >>> <mailto:j...@manicode.com> ha scritto: >>> >>> >>> 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. >> -- >> >> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange >> vittorio.bert...@open-xchange.com <mailto:vittorio.bert...@open-xchange.com> >> Office @ Via Treviso 12, 10144 Torino, Italy > -- > Jim Manico > Manicode Security > https://www.manicode.com > <https://www.manicode.com/>_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
