Re: [OAUTH-WG] Assessing the negative effects of proposed standards

[Jim Manico <jim@xxxxxxxxxxxx>]

How does OAuth harm privacy? This critical delegation use case is user driven, protects leaking user passwords to third party services, limits access to user account features and allows the user to cancel this relationship at any time?

OAuth2 provides more security and privacy than the previous solutions pre-OAuth which was to hand your Twitter credentials (or similar) to a third party service (OAuth clients) exposing your entire account, permanently, to OAuth clients.

OAuth2 radically improves upon this needed web functionality. I don’t see how moving from handing your creds over to a third party to OAuth2 workflows, harms either privacy or security. It improves upon them both.

Also, OAuth2 is hard. It’s a complicated protocol. Delegation is tough. But luckily most developers just need a basic understanding and proper utilization of third party libraries for this need and the ecosystem is is getting much better. For example, PKCE is now integrated into most OAuth libraries.

I advise this working group to take a class or two (as a group, together) from the experts here such as Dr. De Ryck and others so we are all on the same page about what modern OAuth2 solutions really look like and what the OAuth2 framework/protocol actually is.

I am not being combative or trying to hurt anyone when I say that I feel many of the commenters here do not understand the details of OAuth2 and what it’s for.

--

Jim Manico

@Manicode

On Mar 1, 2021, at 6:10 AM, Andrew Campling <andrew.campling@419.consulting> wrote:



On 01/03/2021 10:44 Vittorio Bertola <vittorio.bertola@xxxxxxxxxxxxxxxx> wrote:

 

> Il 26/02/2021 17:32 Aaron Parecki <aaron@xxxxxxxxxxx> ha scritto:

 

 

>> Dynamic client registration does exist in OAuth: https://tools.ietf.org/html/rfc7591

 

>> The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.

 

> This is indeed a matter of product design. I am active in an OIDC-based open identity project where the specs say that providers MUST accept dynamic client registration, without a pre-determined client secret. This is the only way to create a federation that can work on an Internet scale, with relying parties accepting identities managed by providers unknown to them. Then, of course, this also creates lots of opportunities for abuse: you end up in an email-like scenario in which you need ways to ascertain trust in unknown parties and decide whether you want to accept interoperating with them and believe the information they provide, which in turn depends a lot on your specific use case. But we think that that is preferrable to the centralization that is inherent in the original registration model.

 

 

I wonder whether proposed standards should be assessed for their negative properties, eg whether they are likely to exacerbate centralisation, much like security aspects are reviewed.  It may be that a given proposal might still go forward as the trade-offs are deemed worthwhile, however, they would at least be understood and, ideally, documented.  At present there seems to be an exorable drift towards centralisation which, in my view, has a detrimental impact on both resilience and privacy.  Such developments may satisfy the needs of their proponents but are unlikely to be in the long-term interests of end-users (RFC 8890) and, therefore, it would be helpful if this trend wasn’t made worse by the introduction of new standards.

 

 

Andrew Campling

_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth