Get an indirect participant's JWK Set
Returns the JWK Set JDPI signs THIS indirect’s dynamic-QR JWS with, as an application/jwk-set+json document, so the indirect can publish it on its own host for payer PSPs to validate signatures against. The indirect cannot produce this itself — JDPI holds the certificate and does the signing — which is why the convenience lives on the direct participant’s API.
Call it once when onboarding an indirect onto its own QR certificate (after qrCertificate.ownCertificate is set), and again whenever that certificate is rotated; then serve the bytes verbatim at the JWKS location under the indirect’s own base URL. It is read-only and changes nothing here. It is ONLY for an indirect that hosts its own certificate: one that falls back to the direct participant has no key set of its own and is refused 422 PIX-0114, which names the direct participant’s own JWKS route to publish instead. Lifecycle status is deliberately NOT a condition — a SUSPENDED or CLOSED indirect still has live QR codes in the wild, and withholding the key would break their validation.
Every answer carries X-JWK-Set-Freshness: ‘fresh’ when the key set came from inside the cache TTL, or ‘stale’ when the TTL had expired, JDPI could not be reached, and a cached key set was served instead — a 200 alone does not assert freshness, since a cached document and a fresh one are the same bytes. Optional directIspb names the direct participant the indirect is read as; a token confined to one direct participant has to name it. Refusals: 422 PIX-0128 when directIspb names a direct participant this deployment does not act as, before the indirect is read; 404 PIX-0147 when directIspb names a direct participant the indirect is not mounted on; 422 PIX-0111 when this tenant’s indirect-participants feature is not enabled (no QR is signed with any indirect certificate while it is off, so the key set would validate nothing); 404 PIX-0095 for an unknown id; 422 PIX-0114 for the fallback case above; 422 PIX-0098 when the indirect carries no ispb, which is the key §8.3.11 is looked up by; 503 PIX-1050 when JDPI is unreachable and nothing is cached — attributed to JDPI, never presented as a configuration error.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
The indirect participant id.
"018f2b7c-0000-7000-8000-000000000000"
Query Parameters
The ISPB of the direct participant this indirect is addressed as - the one it rides. OPTIONAL: omit it and the indirect is addressed whichever participant it rides, exactly as before. Named, the indirect has to be mounted on that participant, or the answer is 404 PIX-0147 and nothing is read or changed; an ISPB this deployment does not act as is 422 PIX-0128, whether or not the indirect exists. It is ROUTING DATA you supply, never a credential, and a token confined to one direct participant has to name it here. Sending it empty (directIspb=) reads the same as omitting it.
^[0-9]{8}$"87654321"
Response
OK
The JSON Web Keys, exactly as JDPI extracted them from the indirect's CERTQRC certificate.

