feat(node): configure trusted credential issuers

[LKSNDRTMLKV]

Chunk 02 of the audience-access campaign (dpp-docs/work/AUDIENCE-ACCESS-PLAN.md).

What

Binds core's StaticTrustedIssuers to configuration and reports the resulting tier through the existing ghost-honesty port list. Independent of chunk 01 (#60) — no shared code, reviewable on its own.

Three env vars: CREDENTIAL_ISSUERS_LEGITIMATE_INTEREST, CREDENTIAL_ISSUERS_AUTHORITY (comma-separated DIDs), and CREDENTIAL_ISSUERS_SELF=true to trust the node's own operator DID.

Zero-config reports Ghost, not deny-all

An unconfigured node could reject every credential — behaviourally correct, diagnostically useless, and indistinguishable from a rejected issuer or a malformed credential. It instead reports the port as ghost, so /health says the capability is absent rather than the request being wrong.

The port is deliberately not required: a node serving only public views is completely functional. ESPR Art. 11(b) and the toy and detergent regulations require public access free of charge and without registration, so the unauthenticated path is the baseline, not a degraded mode. There is a test asserting the public audience still resolves on an unconfigured node — regressing that would gate public reads behind credential configuration, which those regulations forbid.

The operator as its own issuer

CREDENTIAL_ISSUERS_SELF is opt-in, never implied. It is also the first trust anchor that exists in practice: no EU register of authorised repairers has been established, and the DPP registry registers operators and passports rather than repairer credentials. An operator vouching for its own repair network is real and defensible — but it should be a decision, so it is a flag.

Trust is hierarchical; visibility is not

An issuer trusted to attest an authority may also attest a legitimate interest — the harder attestation implies the easier one. That says nothing about what either credential can see: Audience::may_see still withholds Annex XIII point 4 from authorities regardless of who vouched for them. Both directions are asserted in tests, because conflating them is exactly the mistake the lattice exists to prevent.

Read this with dpp-core#69

Trust checking asks whether issuer is trusted — and DppAccessCredential has no proof member, so issuer is currently a self-asserted string that anyone can set. Until the signed-envelope question is settled, this layer is policy without authentication.

That is not an argument against merging: the configuration and the reporting are needed either way, and nothing gates on them yet. It is an argument against treating chunk 02 as "credential trust is done". Signature verification must land before chunk 04.

Tests

5/5, just check green.

[codacy-production]

Not up to standards ⛔

🔴 Issues 5 high

Alerts:
⚠ 5 issues (≤ 0 issues of at least minor severity)

Results:
5 new issues

Category	Results
Security	5 high

View in Codacy

🟢 Metrics 13 complexity · 0 duplication

Metric	Results
Complexity	13
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[LKSNDRTMLKV]

Folded into #63, which ships the whole credential path as one feature — transport, trusted issuers, signature verification, revocation and the audience-scoped read. The commits from this branch are in that PR's history.