Nobody configured these gateways with the PDP's address or the API's requirements. The API publishes both. A gateway that reads the document finds its PDP and hands the PDP what the API requires; a federation decides whether the document is to be believed. Pick an API, press Discover, and read the chain each gateway followed.
Change the world, then discover again. None of these touches a gateway.
Two discoveries, read top to bottom. First the gateway finds the PDP: it asks the API (RFC 9728
/.well-known/oauth-protected-resource) or the federation (a signed entity configuration, checked against the anchor's policy), reads authzen_policy_decision_points, then asks that PDP where its endpoints are (AuthZEN /.well-known/authzen-configuration). Then the PDP finds what to enforce: the gateway hands it the API's document verbatim, with the endpoint hit and the token, and the PDP reads scopes_supported and acr_values_required out of it.The gateway judged nothing. It compared no scope and no acr. The PDP did, and its reason says so. A gateway that compared them would be policy in two places, and the dumber one would win.
Orange is a PDP identifier. Green is a requirement the PDP will apply. Struck through is what the federation's policy removed from an API's own claim about itself.
Every endpoint is AuthZEN's own name. What differs is the base it hangs off: a PDP identifier may carry a path, and
/tenants/bank-a is what a multi-tenant deployment looks like. A gateway that never read the PDP's metadata assumes the identifier's base, which is fine until the PDP moves.Documents are shown as published now. A step marked fetched was read by that gateway during this run; otherwise it was already in its cache (the demo's TTL is 15 seconds).