FR-05 Facilitate Certificate Lookup Regardless of Location

[danisoler-charin]

Description: The system shall determine which pool operator is responsible for a given certificate (based on PCID, EMAID, or other relevant identifiers) without prior knowledge of that pool.
Use Case: An MO/CPO/OEM needs to retrieve a root/provisioning/contract certificate, but doesn't know which pool holds it
Already in OPNC 1?: This FR has been flagged as Possible but needs more clarification, and "Managed by the AccessToken"

What I have understood is:
The system should figure out automatically:

1. Where the certificate is stored, based on identifiers
2. Query the correct pool operator to retrieve it.
   The AccessToken (from OAuth2) carries information about which pool the certificate belongs to.
   I also understand that this would be currently feasible via broadcast flag mechanism, right?

Does the broadcast actually send to every pool in the ecosystem, or only to known and pre-configured pools?
If new pools join, are they automatically included in broadcast?
How do we check this?

[steffenrhinow]

The sender doesen't need to know in which pool it is stored - it just communicates with one system which needs to to the fuurther comms.
Ech system should send to all onboarded other systems. These systems are preconfigured as we assume that there will not be a lot of the pool operators.
New pool operators can't just join - they need to get accessed and audited by the other systems, as the systems need to rely on a certain level of security and compliance

[danisoler-charin]

After discussion on 09/07/25:
Current feasibility:
The OPNC protocol already supports certificate lookup across pools using a broadcast mechanism. The requester doesn't need to know the exact target pool, as long as:

• The target pools are onboarded and trusted, and
• The call is forwarded to all known pools.

Limitation identified:
The current approach is inefficient, especially as the number of pools grows.
There is no dynamic discovery or centralized registry, meaning each pool must be pre-configured to know all others.

Optional enhancement:
A shared registry or centralized discovery service could help optimize routing and reduce unnecessary API calls, but this is not required for the system to function today.

OPEN: Is it feasible to think now on improving efficiency by implementing a different discovery mechanism or registry?

[marvin-fastned]

Can't we use a similar mechanism (albeit with better security) as OCPI? After a new PNC provider passes the onboarding audit, it will need to establish bilateral connections with each of the other pool providers? This seems manageable if we assume very little new players join the market (which is what I'd personally expect).