EUDI Dev Hub interop

Hvorfor dette sporet finnes

Norsk sandbox er primær akseptansetest for domenet: BRREG/Altinn EBWOID, norske tillitskjeder og Symfoni-flytene. EUDI Dev Hub brukes i tillegg som et lett interoperabilitetsspor for standardprotokollene. Målet er å oppdage avvik i credential_offer, request_uri, response_uri, SD-JWT-VC-format og verifier-respons før de låser seg fast i demo- og produktflyter.

Dette er ikke full ARF-conformance. Første runde skal bare gi et praktisk signal om at walleten oppfører seg rimelig mot EUDI reference tooling.

Neste nivå er dokumentert i EUDI Dev Hub conformance-spor, med must/should/could, egne TEST_EUDI_* gates og tydelig skille mellom automatisk test, manuell runbook, produktkode og utsatte gap.

Kilder og testflater

• EUDI Test overview: Test your Solution
• EUDI issuer-test: Issuer
• EUDI reference repositories: Repositories list
• ARF-protokolloversikt: Architecture and reference framework

Bruk spesielt EUDI issuer eller advanced issuer tester for SD-JWT-VC issuance, og EUDI online verifier når credential type og request matcher det walleten faktisk støtter.

Forutsetninger

• Appen kjører lokalt på http://localhost:3000 eller med offentlig ingress via pnpm dev:ngrok.
• Testbrukeren finnes lokalt, normalt test / test.
• Offeret er SD-JWT-VC. Walleten avviser foreløpig andre credential records i offerflyten.
• Request URI fra verifier ber om en credential type walleten har lagret.
• Engangs-URI-er må leve lenge nok til browser-prefetch og walletens korte resolve-cache.

Issuance med EUDI issuer

1. Start appen med offentlig URL hvis issuer må kalle tilbake til lokal maskin:

   pnpm dev:ngrok

2. Hent et SD-JWT-VC credential offer fra EUDI issuer eller advanced issuer tester. Hvis issuer viser en “Use Wallet Tester”-lenke med credential_offer og tx_code, kan hele den lenken brukes som TEST_CREDENTIAL_OFFER_URI.

3. Kjør OID4VCI-testen med eksisterende env-var:

   TEST_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...' pnpm test:integration --grep OID4VCI

4. Verifiser at credentialet ble lagret og vises i wallet UI.

5. Hvis testen feiler, noter konkret hvor feilen ligger: offer-resolving, issuer metadata, token/credential endpoint, SD-JWT-VC record, x509-trust, lagring eller UI-visning.

Remote presentation med EUDI verifier

1. Sørg for at walleten allerede har et SD-JWT-VC credential som verifier-requesten kan matche.

2. Opprett en EUDI verifier-request med Person Identification Data (PID), dc+sd-jwt, OpenID4VP og GET.

3. Hvis verifieren tilbyr “Specific attributes”, start med felter som finnes i testcredentialet, for eksempel Family name, Given name og Birthdate. “All attributes” kan gi korrekt request-resolving, men likevel ende i “Ingen passende bevis funnet” hvis issuer ikke har utstedt alle feltene.

4. Kopier OPEN WITH YOUR WALLET-lenken. Den er normalt på formen openid4vp://?client_id=...&request_uri=...&request_uri_method=get.

5. Kjør OID4VP-testen med eksisterende env-var:

   TEST_PRESENTATION_REQUEST_URI='openid4vp://?client_id=...&request_uri=...&request_uri_method=get' pnpm test:integration --grep OID4VP

6. Verifiser minst at walleten kan åpne requesten, validere request object, matche credential og vise hva som etterspørres.

7. Hvis presentasjonen ikke kan fullføres, dokumenter årsaken presist som gap. Ikke la det stå igjen som en ukjent feil.

Live EUDI-run 2026-05-08

Dette ble kjørt manuelt mot EUDI issuer/verifier med Playwright:

• Issuance: PID (SD-JWT VC) fra EUDI issuer med Pre-Authorization Code Grant og tx_code bestod. Integrasjonstesten TEST_CREDENTIAL_OFFER_URI='https://tester.issuer.eudiw.dev/redirect_preauth?...&tx_code=...&credential_offer=...' pnpm test:integration --grep 'Full Credential Issuance Flow' passerte, og credentialet ble lagret og vist i UI.
• Trust: EUDI issuer-kjeden manglet i lokal trust store, så Credo traff eksisterende X.509-fallback og lagret credentialet uten full kryptografisk signaturverifisering. Dette er et trust-materiale-gap, ikke et offer parsing-gap.
• Presentation request: EUDI verifier med All attributes ga en gyldig request, men walleten fant ingen matchende credential fordi requesten var bredere enn den utstedte PID-en.
• Presentation request: EUDI verifier med Specific attributes = Family name, Given name, Birthdate, format dc+sd-jwt, profil OpenID4VP, method GET ble løst av walleten og matchet 1 bevis.
• Presentation delivery: Første forsøk stoppet ved KB-JWT-signering fordi en eldre EUDI PID var lagret uten kmsKeyId for holder-bindingen. Etter fixen for jwk-til-kms-key mapping ble en ny EUDI PID utstedt til en ren testbruker, samme verifier-request ble kjørt på nytt, Del bevis sendte direct_post, og EUDI verifier viste 1 documents for urn:eudi:pid:1 i dc+sd-jwt format.

Konkret oppfølging etter live-run:

1. Bruk en ren testbruker eller slett gamle EUDI PID-er før ny VP-test. Eldre credentials som ble lagret før kmsKeyId-fixen kan fortsatt bli valgt først og feile ved KB-JWT-signering.
2. Legg EUDI issuer CA/intermediate inn i lokal trust store for å fjerne X.509-fallbacken. Inntil det er gjort, er interop-resultatet protokollmessig nyttig, men ikke en full kryptografisk trust-godkjenning.
3. Automatiser samme smale EUDI verifier-request når Dev Hub tilbyr stabile fixtures eller et API som ikke krever manuell browser-opprettelse av engangs-URI.

Typiske gap er mismatch mellom verifierens credential query og lagret credential, krav til mDoc/proximity, annen client binding enn walleten støtter, eller trust-materiale som ikke finnes i lokal konfigurasjon.

Ikke-mål i første runde

• mDoc og proximity testing.
• Deferred og dynamic issuance hvis hosted issuer krever mer enn eksisterende Credo-holderflyt håndterer.
• Wallet Unit Attestation, Wallet Instance Attestation og sertifiseringskrav.
• Full conformance mot ARF eller nasjonal sertifisering.

Akseptansekriterier

• Norsk sandbox-flyt med EBWOID fungerer fortsatt som domeneakseptanse.
• EUDI SD-JWT-VC offer kan løses, aksepteres, lagres og vises.
• EUDI OpenID4VP request kan åpnes og presenteres i wallet UI.
• Alle avvik skrives som konkrete gap med kilde, request type, miljø og feilsteg.