Deprecation of oauth* endpoints in Actor objects

[ThisIsMissEm]

Given that these endpoints and how to use them are far better described by RFC 8414's /.well-known/oauth-authorization-server document, which is a widely supported standard, the presence of the OAuth endpoints in Actor objects ties ActivityPub to OAuth as an authentication/authorization mechanism, when this could be discovered by querying for a well known document instead.

This document defined in RFC 8414 is also mostly used by OIDC which uses .well-known/openid-configuration, OIDC also supports discovery via Webfinger request where the link value is http://openid.net/specs/connect/1.0/issuer

Deprecating the properties oauthAuthorizationEndpoint and oauthTokenEndpoint would allow for additional authorization/authentication mechanisms to be experimented with, and would remove the duplication of things already well specified by OAuth 2.0, OAuth 2.1, and OIDC specifications.

[ThisIsMissEm]

This is a follow up to #409 which takes a different approach of proposing we deprecate those endpoints entirely in Actor documents and prefer following other standards.

Perhaps what could be done is to add a property such as authenticationMechanism which is a string representing which specification should be followed for doing authentication, and pre-register oauth2.0, oauth2.1 and oidc?

[evanp]

I am -1 on this. I find these endpoints really useful, and I find the process of endpoint discovery in the actor document to be helpful. FEP-d8c2 uses these endpoints.

Perhaps if we can see another profile defined for OAuth 2.0 and ActivityPub that doesn't use these endpoints, we could use it instead. I still really appreciate the simplicity and directness of this mechanism.

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-d8c2-oauth-2-0-profile-for-the-activitypub-api/3575/19

[ThisIsMissEm]

For what it's worth, Mastodon has added implementing RFC 8414 to their 4.3 milestone, so there's a strong probability that this will land given the PR should be in a mergable state: mastodon/mastodon#24099

[evanp]

@ThisIsMissEm Mastodon only partially supports the ActivityPub API.

[ThisIsMissEm]

@ThisIsMissEm Mastodon only partially supports the ActivityPub API.

As do many other fediverse projects, such as Pixelfed, PeerTube, Lemmy, Kbin, NodeBB, Threads, etc.

Even if these properties are only useful for C2S, it would still be better to defer/delegate to the OAuth 2.0 discovery mechanism as defined in RFC 8414, since that's going to make interoperability much simple.

Assuming scopes, algorithms, authorization flows, etc isn't a good practice.