I fundamentally disagree with this FEP, and think it takes a very “not invented here” approach. Using standards that already exist should be preferable unless there’s a specific reason or value to deviate; Here in this FEP we stand to loose a lot of functionality of OAuth 2.0, and don’t particularly gain anything (besides not having to do Dynamic Client Registration) — but DCR is valuable in other ways.
OAuth 2.0/2.1 is a well defined standard, maintained by the IETF, I don’t think we should be doing something custom just because we’re ActivityPub and can’t be bothered with implementing standards that we don’t directly control. This creates interoperability issues and limits us in how things should work, reduces discoverability of metadata, etc.
We could take an approach more similar to the one defined in solid-oidc, which specifies that you can use a document URI as your client_id when registering the client, such that the details for that client come from an authoritative source, instead of having to provide all the fields when doing registration.
This FEP ignores the fact that you may indeed have confidential clients, not just public clients doing authentication. It all but ignores server to server flows, which impacts building applications for extending server’s capabilities (e.g., something like IFTAS FediCheck or Newsmast)
It’s list of scopes encouraging implementing OAuth 2.0 in ways that reduce consent and allow for data misuse. For instance, many applications that just want to authenticate a user and get basic data from your public profile, but instead they request read scope and now have full access to all your data (I’ve actually opened a PR to Mastodon to implement a read:me scope explicitly to reduce the amount of data an access tokens allows access to by default.
If we remember back to Cambridge Analytica, it was specifically this sort of requesting far more scope permissions in access tokens that were used to gain so much data about so many users, when all the users thought they were doing was signing into some game for fun. We should be educating users to be conscientious about giving access to their data.
Whilst right now the PKCE method of S256 is deemed a security best practice for public clients, it’s not actually necessary for confidential clients, and in the future S256 may no longer be secure enough, given advances in quantum computing or computing power in general, which has often resulted in many cryptographic algorithms becoming obsolete in time.
e.g., would we be better using DPoP tokens instead or in addition?
This FEP also further locks the ActivityPub ecosystem into OAuth 2.0 (maybe OAuth 2.1?), which seems ill-advised.