Discovery Service as a Trust Anchor for P2P Network?

Discovery Service as a Trust Anchor for P2P Network?

Context

I'm designing a P2P network with a central Discovery Service (providing core info about every platform in the network) but no centralised Auth server.

OAuth 2.0 and OpenID Connect will be used for authorisation between platforms in the network. But the network participants still need to know whether other platforms they connect to, or that want to connect to their systems, are officially certified and approved by the central body which governs platform on/off-boarding from the network and the Discovery Registry itself.

For the sake of using the simplest secure solution possible, I'm proposing to use the information provided by the central Discovery Service as a trust anchor within the network. But it’s not a commonly used architecture for trust, so I want input on whether it’s a secure enough approach.

Trust architecture

All participating platforms know that the Discovery Service at api.central-registry.org is the trust anchor. Meaning, we can assume that all platforms know that information from this source is to be trusted (relying on DNS level authentication).

The information delivered by the Discovery Service will include valid API URLs for every single platform in the network. So, when sending an outgoing request for Client Registration, the initiating platform automatically knows that it’s reaching out to a trusted platform. When receiving an incoming request for Client Registration, the requesting platform must have included it’s full set of redirect URIs in the request. The receiving platform should check the entire redirect URI set against the information from the Discovery Service, to verify that the requesting platform is a listed/trusted entity.

Client registration can be successful if the entire redirect URI list is a complete match for the trusted information from the central Discovery Service.

Benefits

1. Low complexity (compared to solutions like using a PKI and CA issued certs)
2. No separate credentials are required
3. No additional steps or processes required, trust is integrated into the steps that are already necessary
4. "Offline" verification to cover for planned and unplanned system outages of the Directory Service is possible by caching the provided information for a predetermined amount of time

Risks

There’s the risk that a platform can use a different URI list when requesting Client Registration. Meaning two things:

1. a client registration from malicious platform A, which uses the redirect URIs of platform B to register it’s client is possible. But the credentials received during the client registration process will be useless since they’ll be valid only for platform B. So there’s no real security risk in handing out useless credentials
2. if there’s a no preventing bad client registrations which use the wrong URI list for the sake of matching the Discovery Service information, then it opens the network to the risk of DOS attacks: by clogging an IDPs list of registered clients with bad/fake registrations.

Weighing the benefits, risks & anything I might have missed, could this trust mechanism be secure enough to rely on?

Note: Digitally signing the Participant Directory List

When retrieving the information from the Discovery Service, if DNS level authentication isn’t enough then network Discovery List delivered by the Discovery Service could be digitally signed using a private/public key pair of the central governing body.