It's amazing how much work these days goes into re-inventing RPC.
HTTP API's, whether using JSON as the data encoding or not, is basically RPC. Celery is decentralized RPC. AMQP is decentralized, unreliable RPC.
It's even a buzzword: microservices are basically "let's use RPC as much as possible".
Anything highly-distributed evolves towards explicit message passing, which is basically... yep, RPC.
You would think we'd have come up with a semi-reasonable general solution by now.
Pretty much anything that isn't an RPC call "hey compute something" is a database query: "hey, give me some data". This is another field where a general-purpose solution, at least for common cases, would be really super nice.
Part of the problem is that we need authentication and authorization to be part of this or else everyone will reinvent their own way.
Kerberos was supposed to handle this but it seems like nobody cares about that anymore.
You can complain about central authorities but there's no reason running one of these key authorities should be any harder than running a DNS server, so it can be as decentralized as you want (distributed is harder; it should be possible, but it's a research project. Decentralized is entirely possible with 1980's technology; see fgure). https://octodon.social/media/ZiBMrqBg7jp6hq6m3wE
Anyway, authorization is the other part of the auth/auth puzzle but by its nature every different service will have to be able to define what it means to them, so it's not a problem that needs interoperability.
The thing is authentication isn't even hard: you have a central authority users register with, that authority that publishes public keys for anyone to look at, and *one way or another* users manage the private keys attached to them. Nobody needs to give a damn how the private keys work as long as it's convenient and secure. Then users just sign messages to prove their origin and anyone receiving the message can verify it.
Instead we have OAuth, which nobody can even explain sensibly.