EUDI sandbox integration checklist

This checklist separates the completed local validation path from the staging steps that require certificates issued by the European Digital Identity (EUDI) Testing Relying Party Registration service.

For the local synthetic relying-party commands, see the [synthetic test setup] (/guide/synthetic-rp).

Local synthetic evidence

• [x] Apply the isolated synthetic D1 migrations: npm run migrate:synthetic.
• [x] Generate synthetic Wallet-Relying Party Access Certificate (WRPAC) and Wallet-Relying Party Registration Certificate (WRPRC) artifacts with npm run generate:rp-certs.
• [x] Seed the generated RP root with npm run seed:rp-test-trust.
• [x] Provision a synthetic RP with npm run provision:rp -- --env synthetic.
• [x] Run the Gateway as npm run dev -- --env synthetic.
• [x] Exercise the mock wallet for PID/SD-JWT or mDOC selective disclosure.
• [x] Verify the session result, redacted realtime update, audit entry, and signed webhook behavior in Gateway tests.
• [x] Run dashboard browser coverage with pnpm --filter dlbr-id-dashboard test:e2e.

Synthetic artifacts and test responses are not EUDI-issued credentials and do not demonstrate interoperability with a production or reference wallet.

Staging certificate intake

1. Register the relying party and request access/registration material in the Testing Relying Party Registration service.

2. Store the downloaded WRPAC PKCS#12 response and its password in an operator secret store. Do not commit the .p12, password, private JWK, or extracted key files.

3. Save the WRPRC service response, including both signed representations, as an operator-controlled JSON artifact.

4. Normalize the material locally:

   npm run import:eudi-rp -- \
     --wrpac-p12 ./downloads/wrpac.json \
     --p12-password "$EUDI_P12_PASSWORD" \
     --wrprc-response ./downloads/wrprc.json \
     --output-dir ./tmp/rp-certs/acme-bank

5. Review wrpac.json, wrpac-private.jwk, and wrprc.json; confirm the client identifier and certificate subjects match the registry response.

6. Apply the additive D1 migration to the staging control-plane database, then provision the RP in staging:

   pnpm exec wrangler d1 migrations apply id-gateway-admin-db-staging \
     --env staging --remote

   The provisioning command keeps the runtime database (id-gateway-db-staging) and the control-plane database (id-gateway-admin-db-staging) in sync. The runtime resolves relying-party metadata from the former, while the operator readiness check reads the latter. Do not provision only one of the two stores.

   npm run provision:rp -- \
     --client-id acme-bank \
     --display-name "Acme Bank" \
     --legal-name "Acme Bank plc" \
     --policy-file ./acme-eudi-policy.json \
     --wrpac-file ./tmp/rp-certs/acme-bank/wrpac.json \
     --wrpac-key-file ./tmp/rp-certs/acme-bank/wrpac-private.jwk \
     --wrprc-file ./tmp/rp-certs/acme-bank/wrprc.json \
     --env staging --remote

7. Seed the staging VERIFIER_KEYS KV from the private JWK using the approved operator procedure. Keep the key out of source control and build artifacts.

8. Set the deployment secret contract before enabling the staging rollout: VERIFIER_KEY_ENCRYPTION_SECRET, TRUST_VALIDATOR_VERIFY_TOKEN, and TRUST_VALIDATOR_PROVISIONING_TOKEN on the Gateway Worker; and TRUST_VALIDATOR_VERIFY_TOKEN, PROVISIONING_TOKEN, and TRUST_VALIDATOR_ROOTS_DER on the trust-validator Worker. Use Wrangler's interactive secret prompt or the approved secret manager; never put values in GitHub workflow YAML, command arguments, logs, or artifacts. CI checks only the deployed secret names with wrangler secret list and fails closed if any required name is absent.

9. Confirm the relying party appears as ACTIVE in the dashboard and that the staging readiness check reports registration.

Evidence pack

Capture the following for the sandbox handoff, with secrets and personal data redacted:

• commit SHA and validation output;
• migration names and environment (staging, never synthetic for sandbox evidence);
• registry request/response identifiers and certificate fingerprints;
• WRPAC leaf subject, issuer, validity window, SAN, and chain length;
• WRPRC JAdES and COSE presence plus signature-validation result;
• RP policy JSON and provisioned client identifier;
• OID4VP request URI/profile (inline or jar), selected claims, and wallet response status;
• verification result, verification details, audit entry hash, and webhook delivery/retry result;
• negative-test results for invalid signature, expired certificate, missing RP registration, failed webhook, and rate-limit behavior.

Never include private keys, passwords, bearer/API keys, raw PID claims, full wallet payloads, or unredacted webhook bodies in the evidence pack.

References

• EUDI Testing RP Registration guide
• EUDI Wallet Reference Implementation organization
• EUDI Wallet developer documentation