EUDI Dev Hub conformance-spor

Formål

Det lette EUDI Dev Hub interop-sporet viser at walleten kan snakke med EUDI reference tooling for SD-JWT-VC issuance og OpenID4VP remote presentation. Dette conformance-sporet er neste nivå: samme verktøy, men med tydelig kravliste, gates og beslutning om hva som er automatisk test, manuell runbook, ny produktkode eller utsatt.

Dette er fortsatt ikke en formell sertifisering. Det er en repo-nær compliance-prøve som skal gjøre gapene presise før vi investerer i større arkitektur.

Kilder

• EUDI testverktøy: Test your Solution
• EUDI issuer: Issuer
• EUDI online verifier: Online Verifier
• ARF: Architecture and Reference Framework
• OpenID4VCI 1.0 Final: OpenID for Verifiable Credential Issuance
• OpenID4VP 1.0: OpenID for Verifiable Presentations

EUDI issuer-verktøyet dekker credential offer, pre-authorisation, deferred og dynamic issuance, og både mDoc og SD-JWT. Online verifier brukes for remote OpenID4VP. ARF legger i tillegg krav rundt issuer/RP trust, Wallet Unit/Instance Attestation, revocation, device binding, disclosure policy og både remote og proximity presentation.

X.509 trust for EUDI hosted issuer

Live PID SD-JWT VC issuance fra https://issuer.eudiw.dev / https://backend.issuer.eudiw.dev bruker EUDI Dev Hub sin Utopia-test-CA:

EUDI TrustProvider Signer sin konfigurasjon har PID Issuer CA - UT 02 som default CA for testland UT, og server/issuersCertificates er repoets lokale trusted-list mappe for issuer-CA-er. EUDI issuer-docs peker på hosted issuer-verktøyet på issuer.eudiw.dev, mens live issuer metadata for PID SD-JWT VC annonserer credential_issuer=https://backend.issuer.eudiw.dev, format=dc+sd-jwt og vct=urn:eudi:pid:1.

Dette materialet er test/conformance-trust for EUDI Dev Hub, ikke produksjons-policy.

Arkitektur-spike: mDoc/proximity og wallet-attestasjon

Dette er en spike-beslutning, ikke en produktleveranse. Repoet skal ikke late som mDoc/proximity, Wallet Unit Attestation eller Wallet Instance Attestation er dekket av dagens automatiske tester. Første nyttige leveranse er å bevise parsing, trust og testbarhet med små fixtures og en manuell proximity-runbook.

app.db har nå bare DB-backed mDoc-metadata for spike-sporet: dokument-id, wallet-id, doctype, namespaces, issuer/fingerprint, gyldighet, offer-hash og livssyklusstatus. Rå mDoc CBOR, private device keys, access tokens, WUA secrets og WIA secrets skal ikke lagres i app.db.

WUA/WIA ligger fortsatt som planleggingsrecords og negative tester. Standard Wallet Unit-modell er tenant-wallet, men status skal være blocked-by-wallet-unit-decision eller not-implemented til Wallet Unit, revocation og attestation policy er avklart.

ARF skiller remote og proximity presentation: remote bruker OpenID4VP, mens proximity bruker ISO/IEC 18013-5. ARF beskriver også at Wallet Provider Interface utsteder Wallet Unit Attestation, og at WUA brukes under aktivering og senere ved issuance for å bevise wallet-kapasiteter og nøkkelbesittelse. PID-regelboken beskriver Wallet Instance Attestation som et eget dokument med doctype og namespace eu.europa.ec.eudi.wallet-instance.1, men sier samtidig at komplett datamodell ikke er spesifisert der ennå. Derfor må WUA/WIA behandles som arkitekturspike og interoperabilitetsavklaring før produktkode.

Nåværende repo-status:

Konsekvens: dagens pnpm check, pnpm test:unit og Playwright-spor kan bare bevise SD-JWT-VC issuance, remote VP, tenant-isolert lagring og eksisterende X.509-trustlogikk. De kan ikke gi grønt lys for mDoc/proximity eller WUA/WIA.

Minste spike for neste agent

Målet er en bevisst smal spike som kan slettes eller utvides uten å låse produktarkitekturen.

1. Biblioteker:
   • For repo-nær TypeScript-fixture: vurder @auth0/mdl for å parse og validere CBOR-encoded mdoc/MSO, cbor-x for lavnivå CBOR-inspeksjon, cose-js for COSE-signaturer hvis @auth0/mdl ikke dekker hele behovet, og @noble/curves bare hvis WebCrypto/Credo KMS ikke dekker P-256-operasjoner i test.
   • For reell proximity: bruk EUDI Android Wallet Core/proximity-referansen eller EUDI Proximity Verifier Core som separat harness. Ikke prøv å bygge BLE/NFC i SvelteKit-serveren.
2. Data stores:
   • Behold app.db til wallet metadata: mdoc document id, doctype, namespace, issuer, validity, tenant id, trust-status, revocation/status-url og referanse til key id.
   • Behold historikk.db til issuance/presentation-hendelser.
   • Bruk Askar/KMS for private nøkler hvis Credo kan eksponere nødvendig key-materiale. Hvis ikke, lag en spike-adapter som bare peker på ekstern secure area/harness; ikke lagre private device keys i SQLite.
   • Legg IACA/root/link certificates under en egen trust-materiale-katalog eller env-konfig som speiler X509_EXTRA_TRUST_CERT_*, men kall den eksplisitt MDOC_IACA_CERT_PATHS, MDOC_IACA_CERT_PEM og MDOC_IACA_CERT_URLS for å unngå å blande SD-JWT og mdoc trust.
3. Routes:
   • GET /app/credential/offer skal i første spike bare klassifisere mso_mdoc/org.iso.18013.5.1.mDL og vise “ikke støttet” med diagnostics. Full acceptance skal vente.
   • POST /app/credential/offer?/acceptMdoc kan komme senere når storage og key binding er avklart.
   • GET /api/lab/mdoc/fixture/:id kan brukes for intern fixture-inspeksjon uten produktflyt.
   • Proximity skal starte som ekstern Android/iOS harness, ikke web-route.
   • WUA spike trenger senere /.well-known/jwt-issuer, /api/wallet-provider/wua/token eller tilsvarende provider-endepunkt, men bare etter at Wallet Unit-modellen er valgt.
4. Cert/trust-materialer:
   • EUDI issuer/tester CA/intermediate for SD-JWT skal fortsatt inn via X509_EXTRA_TRUST_CERT_*.
   • mDoc trenger IACA root/link/document signer chain separat, med OID/profilvalidering for PID/mDL og reader authentication.
   • RP/proximity reader certificate må behandles som verifier trust-materiale og knyttes til reader auth, ikke til issuer trust.
5. EUDI Dev Hub-scenarioer:
   • Issuer: PID eller mDL i mso_mdoc/mDoc-format med pre-authorized flow, først forventet kontrollert avvisning, deretter fixture-basert parsing.
   • Proximity Verifier: EUDI Proximity Verifier app eller core med QR device engagement og BLE transfer.
   • Remote verifier skal ikke brukes som proxy for proximity-conformance.
   • WUA/WIA: start med dokumentert issuer/token-request forventning og negativ test som bekrefter at repoet ikke sender client attestation headers før produktmodell finnes.

Anbefalt rekkefølge

1. Sikre SD-JWT-sporet: fjern X.509-fallback for EUDI issuer ved å legge riktig CA/intermediate i trust store og gjør TEST_EUDI_REQUIRE_TRUSTED_ISSUER_CHAIN=1 til krav for conformance-run.
2. Lag mdoc fixture-spike uten issuance: parse en kjent mdoc/MSO, valider doctype/namespace, issuer chain og digest, og dokumenter resultatet i docs.
3. Legg inn kontrollert mdoc-offer gate i offerflyten: mso_mdoc skal gi eksplisitt unsupported-feil, ikke “SD-JWT pass”.
4. Kjør manuell EUDI mDoc issuance mot Dev Hub og lagre bare runbook-resultat, ikke credential.
5. Bygg proximity harness utenfor SvelteKit: Android/iOS/EUDI reference core med QR og BLE, der repoet bare eier fixtures, trust-materiale og resultatlogg.
6. Avklar Wallet Unit-modell for SaaS: per organisasjon, per bruker, per browser-enhet eller per ekstern device. WUA/WIA kan ikke implementeres riktig før dette er bestemt.
7. Først deretter: WUA client attestation, WUA status/revocation, WIA data model og issuer-side validering.

Ikke bygg nå

• Ikke implementer BLE/NFC, ISO 18013-5 session transcript eller DeviceResponse i SvelteKit-produktkoden.
• Ikke lag en “fake WUA” bare for å få EUDI issuer videre. Det vil skjule at Wallet Unit, revocation og attestation policy mangler.
• Ikke bland IACA trust inn i dagens SD-JWT X509_EXTRA_TRUST_CERT_* uten eksplisitt namespace og tester.
• Ikke lagre mdoc private device keys i app.db.
• Ikke selg WIA som ferdig før ARF/regelbok og Dev Hub-scenarioet har stabil datamodell for akkurat feltsettet vi bruker.
• Ikke gjør mDoc/proximity til del av samme grønnløype som SD-JWT-VC. Det skal være et separat spor med egne gates.

Scope

Must

• SD-JWT-VC PID issuance fra EUDI issuer eller advanced issuer tester med Pre-Authorization Code Grant og tx_code.
• OpenID4VCI offer parsing for både credential_offer_uri og inline credential_offer.
• Eksplisitt klassifisering av offer som pre-authorized, authorization-code, mixed, deferred-capable eller ukjent før live-run markeres som conformance-resultat.
• Wallet-lagring og UI-visning etter at bruker godkjenner credential.
• Remote OpenID4VP request resolving fra EUDI online verifier med request_uri, client_id, dc+sd-jwt og GET.
• DCQL/credential matching for en smal PID-request som bare ber om attributter credentialet faktisk har.
• Direct post delivery som eksplisitt opt-in i conformance mode, fordi Dev Hub requestene ofte er engangs-URI-er.
• X.509 trust-resultat skal klassifiseres: full trust, fallback eller feil. Fallback er et gap, ikke pass.

Should

• Gjenta samme run med en ren testbruker og tom Askar-store for å unngå gamle PID-er uten komplett holder-binding.
• Kjøre samme VP-request to ganger: først inspect-only, deretter med TEST_EUDI_SUBMIT_PRESENTATION=1.
• Bruke egne env-variabler for EUDI deferred/dynamic offer-URI-er slik at single-use pre-authorized smoke ikke blandes med gap-sporet.
• Dokumentere exact credential format, vct, issuer, verifier, request type, selected attributes og trust-status for hver live-run.
• Legge EUDI issuer CA/intermediate i X509_EXTRA_TRUST_CERT_PATHS eller X509_EXTRA_TRUST_CERT_URLS når materialet er tilgjengelig, slik at fallback kan fjernes.
• Fange verifier-feilrespons, ikke bare wallet-UI.

Could

• Deferred issuance i EUDI advanced issuer tester med opt-in pending-flyt, manuell polling og historikk.
• Dynamic issuance som smal authorization-code smoke når walletens WALLET_CLIENT_ID og redirect URI er registrert hos issuer og forventet credential request er avklart.
• Flere credential typer enn PID hvis Dev Hub tilbyr stabile SD-JWT-VC requests som matcher walletens display og matchinglogikk.
• Automatisk Dev Hub verifier-opprettelse dersom verktøyet får et stabilt API eller en dokumentert fixture-mekanisme.
• Proximity verifier og mDoc som separat teknisk spor når produktet faktisk har mDoc-dataflyt, IACA-trust og ISO 18013-5 transport.

Gap-analyse for deferred og dynamic issuance

OpenID4VCI 1.0 Final skiller mellom vanlig credential endpoint og valgfritt deferred credential endpoint. Når issuer ikke kan levere credentialet med en gang, returnerer credential response en pending transaksjon med transaction_id; walleten må senere POST-e transaction_id til deferred_credential_endpoint med gyldig access token. For dynamic issuance brukes authorization-code-flyten der walleten ber om credential via authorization_details/credential_configuration_id, eventuelt med claim-utvalg.

Credo 0.7 støtter mer enn appen bruker i dag:

Lavrisiko som er implementert nå:

• classifyOpenId4VciResolvedOffer klassifiserer grants, credential configuration IDs, dynamic authorization-code kandidat og om issuer metadata annonserer deferred_credential_endpoint.
• Pre-authorized og authorization-code callback stopper tydelig hvis Credo returnerer deferredCredentials uten at deferred-flyten er aktivert, i stedet for å ende som generisk “ingen credential mottatt”.
• Når OID4VCI_DEFERRED_ISSUANCE_ENABLED=1 er satt, persisterer appen pending issuance state, viser /app/credential/pending/[pendingId], poller manuelt mot issuer og logger credential_pending, credential_ready, credential_poll_failed, credential_issuance_expired og credential_issuance_cancelled.
• Test-fixtures har egne deferred/dynamic offer-eksempler og env aliases.
• Playwright-sporet har eksplisitte skip for deferred/dynamic live automation til stabile EUDI live-kriterier og secrets-policy er avklart.

Det som ikke er implementert nå:

• Ingen bakgrunnsjobb eller automatisk retry mot deferred_credential_endpoint; bruker må poll-e manuelt fra pending-siden.
• Ingen kryptert/roterbar secrets-store for pending accessToken/DPoP state; prototypen lagrer dette i app.db sammen med pending record.
• Ingen automatisk Playwright-liveflyt for EUDI deferred issuance, fordi test-URI-er/secrets og timing fortsatt må styres manuelt.
• Ingen dynamisk claims/credential-selector for issuer-initierte authorization-code flows utover det Credo løser fra offeret.

Hva vi kan teste automatisk nå

Kjør først basis:

pnpm check
pnpm test:unit
pnpm test:integration --grep "OID4VCI|OID4VP"

Conformance-env bruker egne aliaser, men fallbacker til de gamle interop-variablene:

TEST_EUDI_CONFORMANCE_TRACK=1 
X509_EXTRA_TRUST_CERT_PATHS=certs/eudi-dev-hub/PIDIssuerCA02-UT.cacert.pem 
TEST_EUDI_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...' 
pnpm test:integration --grep "Full Credential Issuance Flow"

Når TEST_EUDI_CONFORMANCE_TRACK=1 er satt, avviser wallet-koden SD-JWT VC-lagring via uverifisert fallback. En issuance-run teller derfor bare som conformance-pass hvis Credo validerer x5c-kjeden mot trust-materialet over og testen passerer uten advarselen Lagrer SD-JWT VC uten signaturverifisering.

Live-status 2026-05-11: trust anchor-feilen No trusted certificate was found while validating the X.509 chain er erstattet av en strengere issuer/SAN-feil når UT02-fixturen brukes. Det utstedte credentialet har iss=https://backend.issuer.eudiw.dev, mens x5c leaf PID DS - 011 annonserer SAN-DNS issuer.eudiw.dev. Credo avviser derfor credentialet med x509-issuer-san-mismatch, og conformance issuance skal fortsatt stå som fail til issuer-kjeden eller issuer-claimen matcher.

For EUDI online verifier med client_id=x509_hash:... må verifierens access-certificate-kjede også ligge i trust-materialet når TEST_EUDI_CONFORMANCE_TRACK=1 brukes. Test-fixturen under certs/eudi-dev-hub/VerifierEndpointAccessChain.pem er eksportert fra EUDI verifier endpoint-repoets src/main/resources/keystore.jks med alias access_certificate. Uten den stopper request resolving før matching med No trusted certificate was found while validating the X.509 chain.

Deferred og dynamic er foreløpig gap-spor. De skal ikke forventes å gi grønn live-test før produktstøtten under “Krever ny produktkode” er bygget:

TEST_EUDI_CONFORMANCE_TRACK=1 
TEST_EUDI_DEFERRED_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_deferred?...' 
pnpm test:integration --grep "EUDI Deferred and Dynamic Issuance Gaps"

TEST_EUDI_CONFORMANCE_TRACK=1 
TEST_EUDI_DYNAMIC_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_dynamic?...' 
WALLET_CLIENT_ID='registrert-wallet-client-id' 
pnpm test:integration --grep "EUDI Deferred and Dynamic Issuance Gaps"

Inspect-only VP, uten å bruke opp verifier-sessionen på direct post:

TEST_EUDI_CONFORMANCE_TRACK=1 
X509_EXTRA_TRUST_CERT_PATHS=certs/eudi-dev-hub/PIDIssuerCA02-UT.cacert.pem,certs/eudi-dev-hub/VerifierEndpointAccessChain.pem 
TEST_EUDI_PRESENTATION_REQUEST_URI='openid4vp://?client_id=...&request_uri=...&request_uri_method=get' 
pnpm test:integration --grep "should display presentation request UI elements"

Full VP delivery, eksplisitt opt-in:

TEST_EUDI_CONFORMANCE_TRACK=1 
TEST_EUDI_SUBMIT_PRESENTATION=1 
X509_EXTRA_TRUST_CERT_PATHS=certs/eudi-dev-hub/PIDIssuerCA02-UT.cacert.pem,certs/eudi-dev-hub/VerifierEndpointAccessChain.pem 
TEST_EUDI_PRESENTATION_REQUEST_URI='openid4vp://?client_id=...&request_uri=...&request_uri_method=get' 
pnpm test:integration --grep "should complete presentation exchange"

EUDI online verifierens request_uri er engangsbruk på request-object fetch. En inspect-only test som løser requesten kan derfor gjøre samme URL ugyldig for en senere prosess. Lag en ny verifier-request med samme valg for delivery hvis inspect og delivery kjøres som separate Playwright-kommandoer.

Automatisk dekning akkurat nå:

Manuell runbook

1. Start lokalt eller med ngrok:

   pnpm dev
   # eller
   pnpm dev:ngrok

2. Nullstill testdata hvis du skal måle conformance, ikke bare debugge:

   rm -rf ~/.afj/data/wallet/root/ app.db* historikk.db*

3. Hent PID (SD-JWT VC) fra EUDI issuer eller advanced issuer tester. Velg pre-authorized code med tx_code først.

4. Kjør issuance-kommandoen over med X509_EXTRA_TRUST_CERT_PATHS=certs/eudi-dev-hub/PIDIssuerCA02-UT.cacert.pem og noter issuer, credential type, format, vct, grant type og trust-status. Hvis testen feiler med x509-issuer-san-mismatch, er trust anchor lastet, men issuerens iss matcher ikke x5c leaf SAN. Hvis testen feiler med x509-trust-chain, mangler eller matcher ikke trust-materialet.

5. Opprett EUDI online verifier-request med Person Identification Data (PID), dc+sd-jwt, OpenID4VP, GET og Specific attributes. Start smalt med family_name, given_name og birth_date/birthdate, avhengig av hva den utstedte PID-en faktisk inneholder.

6. Kjør inspect-only VP med både issuer-CA og verifier access chain i X509_EXTRA_TRUST_CERT_PATHS. Hvis den ikke matcher, noter om feilen ligger i request object, client binding, credential format, vct, attributtnavn eller lokal wallet-state.

7. Kjør delivery med TEST_EUDI_SUBMIT_PRESENTATION=1 først når du er klar til å bruke opp requesten. Hvis inspect allerede har fetchet request-object, lag en ny identisk verifier-request for delivery. Verifiser resultatet i EUDI verifier UI.

8. Ta skjermbilde eller logg URL, tidspunkt, commit SHA og kommandoene i arbeidsnotatet.

For deferred/dynamic manuell undersøkelse:

1. Hent offer fra EUDI Advanced issuance tester, ikke basic smoke, slik at du kan se steg og status.
2. Kjør grep-sporet over først. Playwright-liveautomatiseringen er fortsatt skip-et, men opt-in produktflyten kan testes manuelt.
3. Hvis du debugger lokalt med verbose logger, sett OFFER_VERBOSE_LOGS=1 og les Offer classification.
4. Hvis deferred faktisk returneres, noter credentialConfigurationId, transactionId, interval og om issuer metadata har deferred_credential_endpoint.
5. For manuell produktflyt: sett OID4VCI_DEFERRED_ISSUANCE_ENABLED=1, åpne pending-siden og poll derfra, slik at access token, DPoP state, KMS key mapping, expiry og bruker-/wallet-binding blir lagret og historikkført samlet.

Krever ny produktkode

• Global fjerning av X.509-fallback krever en bredere policy for hva wallet skal gjøre når trust mangler. EUDI conformance-runs er harde på dette via TEST_EUDI_CONFORMANCE_TRACK=1, mens generiske live-runs beholder fallback som interop-workaround.
• Deferred issuance har nå en opt-in brukerflyt for pending credential, manuell polling, retry-telling og historikk. Før dette kan kalles produksjonsklart trengs bakgrunnsjobb/auto-retry, avklart secrets-policy for access token/DPoP state, opprydding av utløpte records og live-testkriterier for EUDI advanced issuer.
• Dynamic issuance krever tydelig UX og kode for authorization-code-baserte offers utover dagens happy path: client registration, redirect allowlist, authorization details/claims, consent copy, state cleanup og feilhåndtering når issuer ber om presentation-during-issuance.
• Revocation/status-list validering må kobles til credential-lagring og presentasjon, ikke bare display.
• Embedded disclosure policy må hentes, lagres og evalueres hvis issuer metadata tilbyr det.
• WUA/WIA krever wallet-provider-modell, attestasjon, nøkkelbinding, revocation og issuer-side validering. Det skal ikke presses inn som en test-hack.
• mDoc/proximity krever mDoc credential model, IACA trust, ISO 18013-5 transport og proximity verifier-runbook.

Bør vente

• Full ARF-conformance og sertifiseringsspråk.
• Proximity/mDoc som del av samme grønnløype som SD-JWT-VC.
• Produksjonsbeslutninger om Wallet Unit Attestation, Wallet Instance Attestation og WSCA/WSCD før prototypearkitekturen er mer stabil.
• Automatisk Dev Hub UI-automatisering som eneste kilde til pass/fail. Den er nyttig for smoke, men for conformance trenger vi stabile fixtures eller API-er.

Pass/fail-regel

En conformance-run er pass bare når:

• issuance og VP inspect passerer på ren testbruker,
• full VP delivery passerer med eksplisitt opt-in,
• trust-status er dokumentert som full trust, ikke x509-trust-chain, x509-issuer-san-mismatch eller fallback,
• alle gap er klassifisert som automatisk, manuell, produktkode eller utsatt.

Hvis credentialet lagres via X.509-fallback, er resultatet interop-pass, conformance-gap.

Med TEST_EUDI_CONFORMANCE_TRACK=1 skal fallback ikke lenger kunne gi grønn issuance-test. Testen skal feile hvis verifisert lagring ikke fungerer.

Neste agent

1. Kjør ny live issuance med X509_EXTRA_TRUST_CERT_PATHS=certs/eudi-dev-hub/PIDIssuerCA02-UT.cacert.pem og bekreft at ingen X.509-fallback brukes.
2. Legg en .context/eudi-conformance-run-YYYY-MM-DD.md per live-run med kommandoer, commit SHA, Dev Hub valg og resultat.
3. Verifiser om request_uri_method=get bør sendes videre fra wallet-route til Credo-resolveren, eller om default GET er tilstrekkelig.
4. Bygg deferred pending-modellen før live-testen gjøres grønn: persistent state, polling-endepunkt/job, historikk og UI for “venter på utsteder”.
5. Lag en egen mDoc/proximity spike først når walletens mDoc-lagring og IACA trust er definert.