Some changes to the User object are inevitable when introducing Authority. But the project is designed to postpone breaking changes, and we can mark any additions as internal or unstable, so we don't commit to keeping them stable.
Asynchronous "jobs" run in MediaWiki itself, so there are no other systems involved. MediaWiki is only a monolith when you look at it in a component diagram. If you look at a process/communication diagram, it's an event based architecture (and has been for many years).
Currently, a user may be prevented from editing because the user is blocked, or the IP they are coming in from is blocked. But once the edit is made and async jobs have been scheduled, these jobs are executed with the user's permissions, without IP based restrictions. The same applies to OAuth grants: the apply in the original request, but not in async jobs later.
With authority, we can just determine and serialize the list of permissions a job should have, based on the current request, when scheduling the job. This way the job will then execute with only the given permissions. With the Authority interface, this becomes really straight forward.
Note that this requires some changes to the Job system which wouldn't be included in the first iteration of this. But introducing Authority enables this kind of logic.
