Pro:

• Allows creating simple stateless clients which just check the access token rathet than having to call an API (and then probably cache the results of that API call).

Con:

• There is no way to ensure the timeliness of the information in an access token; e.g. the user might have retracted the authorization represented by the token in the meantime, but a client inspecting the access token rather than calling the UserInfo endpoint wouldn't know that.
• Puts the burden on clients to get the sometimes tricky details of access token security right (see e.g. the Misuse of Access Token to Impersonate Resource Owner in Implicit Flow section of the OAuth 2 spec).
• Precludes us from putting secret information (e.g. abuse risk scores) in the access token in the future. The access token is an efficient way to communicate key facts about a client to other parts of the Wikimedia infrastructure (see T394012: Decide how to expose session information outside of MediaWiki).
• The public keys used to sign access tokens would de facto become an API with stability expectations; chaging encryption keys would become more onerous.

@JTweed-WMF pointed out elsewhere that we'll need a mechanism to share JWT keys between various layers of our infrastructure. That could be done via puppet (which is what we do today), but it might be more flexible to do it via a JWKS web endpoint, at which point making it publicly available (e.g. using the conventional .well-known/jwks.json) is not much extra effort.

From a security perspective, this seems reasonable as long as it’s paired with the usual safeguards: short-lived tokens, proper key rotation, minimal claims, and good client validation guidance. It’s a common pattern across the industry.

As I’m not deep in the implementation, I’d also recommend looping in other folks who might be impacted by token handling or infrastructure changes.