Establishing identity within a group of services

How can a group of services determine each other's identity?

For the purpose of this discussion, the services are connected (indirectly) to each other over a network, and the services are capable of storing secrets, which can be securely distributed to the services.  A central service can also exist with which all other services can authenticate i.e. have a trusted connection to.

If the central service establishes itself as the registration authority, it can issue credentials e.g. secret key, password, private key etc., then we have a group where every service that registers can authenticate itself back to the central service in the future.  That doesn't immediately allow services to identify themselves to other services.

We usually have additional constraints though, such as
- service-to-service identification should not have to involve the central service every time services communicate, but bootstrapping via trusted centralised information, or occasionally talk to the central component is acceptable
- the overhead of proving identity should not be a burden
- direct connections between services don't exist e.g. there are intermediate network devices
- replay attacks should not work
- stealing credentials is not in our threat model, but stealing ephemeral credentials should not lead to permanent compromise of an identity

Secret Key pairs
A central service can hand out keys unique to every pair of services, and that way each service can sign a message and the receiving service will know it must have originated from them because only they have the key.  For N services that requires managing O(N^2) keys.  Keys would need an identifier, a lifetime and to be rotated, all without causing any downtime or miscommunication.  Creating signatures would be simple and signatures would be small.

PKI
Each component can get an asymmetric key, and then sign a message and the receiving component will verify the signature via the public key, which it obtains from a central trusted location, and it will then know it must have originated from the signer because only they have the private key.  For N services that requires managing O(N) keys.  Keys would need an identifier, a lifetime and to be rotated, all without causing any downtime or miscommunication.  Signatures that would be sent would be somewhat large ~ 1-2KB.

Mutual-TLS
This implies that either the TLS is terminated at each component, or if terminated at some intermediate network point the client certificate is transmitted as an HTTP header.  The same constraints as for PKI exist. 

OIDC/OAuth2
Each service (client) gets an ID Token for each other service (Relying Party) it needs to talk to (the ID Token audience would be the Relying Party service).  The lifetime of the ID Token would control how often each component needs to talk to the central component.  For N services that requires managing O(N) secrets.  The tokens used would need to be regularly refreshed at the central service.

Kerberos
Designed to solve this problem, but difficult to understand and get assurance of security.

There are likely others I am missing.