OpenID4VP

Hva protokollen gjør

OpenID4VP lar en mottaker beskrive hvilke bevis eller opplysninger den trenger. Lommeboken matcher forespørselen mot tilgjengelige bevis, viser valget til brukeren og sender en verifiserbar presentasjon tilbake.

Grunnflyten

1. Mottakeren lager et signert request object eller publiserer det på request_uri.
2. Brukeren åpner forespørselen i lommeboken.
3. Lommeboken validerer forespørselen og finner bevis som passer DCQL.
4. Brukeren godkjenner eller avslår.
5. Svaret sendes som direct_post til mottakerens response_uri.

Dette binder svaret

• nonce binder presentasjonen til utfordringen.
• state lar mottakeren koble svaret til egen transaksjon.
• client_id og request-signaturen bindes til mottakeren gjennom mekanismen som følger av valgt prefix, for eksempel sertifikatkjede, verifier-attestasjon, føderasjon eller forhåndsregistrering.
• response_uri bestemmer hvor svaret leveres.
• Holder-binding viser at lommeboken kontrollerer nøkkelen som beviset er bundet til.

Mottakeren må kontrollere alle relevante bindinger, signaturer, gyldighet og status før opplysningene brukes.

Symfoni-støtte

Symfoni støtter remote OpenID4VP med DCQL, GET- og POST-baserte request_uri-oppslag, brukergodkjenning og avslag. OpenID4VP 1.0 Final bruker DCQL. Symfoni kan i tillegg lese Presentation Exchange for kompatibilitet med eldre OpenID4VP-utkast; nye integrasjoner bør bruke DCQL. Proximity-flyter med mdoc, Bluetooth eller NFC støttes ikke.

Ved virksomhetsforsegling brukes transaction_data i tillegg. Forseglede dokumenter sendes separat til mottakerens dispatch.url; de er ikke en del av selve vp_token.

Test negative tilfeller

Prøv utløpt eller gjenbrukt nonce, endret callback, ukjent state, feil request-signatur og et bevis som ikke oppfyller forespørselen. Et forståelig avslag er også en viktig interoperabilitetstest.