DCQL forklart: slik ber en verifikator en lommebok om nøyaktig det den trenger
DCQL, Digital Credentials Query Language, er den omforente måten en virksomhet forteller en lommebok hvilke legitimasjonsbevis den trenger og hvilke opplysninger inne i dem. Det er dette som gjør en forespørsel som "bevis at selskapet ditt er registrert i Nederland" til noe enhver kompatibel lommebok forstår, uten en egen integrasjon per lommebok.
Problemet DCQL løser
En forretningslommebok inneholder legitimasjonsbevis av mange slag, utstedt av ulike organer i ulike land og lagret i ulike tekniske formater. En virksomhet som bare trenger å bekrefte et organisasjonsnummer og et juridisk navn, har ingen portabel måte å be om nøyaktig det. Den ender enten med å ta hele beviset, med alt annet som ligger i det, eller med å bygge en egen integrasjon for hver lommebok den møter.
DCQL løser spørresiden. Én standardforespørsel navngir legitimasjonsbevisene som ønskes og de bestemte opplysningene som ønskes fra hvert av dem. Lommeboken sjekker den mot det innehaveren faktisk har, viser innehaveren hva det spørres om, og deler bare det. Verifikatoren får et forutsigbart svar uansett hvilken lommebok innehaveren bruker.
1. Verifikator
Ber om nøyaktig de legitimasjonsbevisene og opplysningene den trenger
2. Lommebok
Finner ut hvilke av de lagrede legitimasjonsbevisene som passer forespørselen
3. Innehaver
Ser hva det spørres om og godkjenner at bare det deles
4. Verifikator
Mottar de godkjente opplysningene, og ikke noe mer
Hva en verifikator kan be om
En forespørsel er en kort liste over hva som trengs. Den kan navngi ett legitimasjonsbevis eller flere, og for hvert av dem kan den navngi de bestemte opplysningene som ønskes i stedet for hele beviset. Tre valg i tillegg dekker nesten alle reelle tilfeller: reservealternativer, kombinasjoner og en grense for hvilke utstedere som godtas.
- Hvilke legitimasjonsbevis som trengs, og hvilke opplysninger inne i hvert av dem.
- Akseptable reservealternativer, i prioritert rekkefølge, for innehavere som ikke har alt.
- Kombinasjoner, slik at en forespørsel kan kreve ett legitimasjonsbevis og ett av to andre.
- En begrensning til utstedere på en offisiell tiltrodd liste, slik at legitimasjonsbevis fra andre aldri tilbys.
Å be om et reservealternativ
Ikke alle innehavere har det samme legitimasjonsbeviset. En verifikator kan angi hva den helst vil ha og hva den fortsatt godtar, i prioritert rekkefølge, og lommeboken bruker det beste alternativet innehaveren faktisk kan oppfylle. Det sparer en ekstra runde og hindrer at en kunde blir avvist bare fordi en detalj det var fint å ha, mangler.
1. Foretrukket
Brukes når legitimasjonsbeviset inneholder begge
2. Reserve
Brukes bare når det første alternativet ikke kan oppfylles
Her vil verifikatoren helst ha et organisasjonsnummer sammen med det juridiske navnet, men godtar det juridiske navnet alene når innehaverens legitimasjonsbevis ikke inneholder et organisasjonsnummer.
Å kombinere legitimasjonsbevis i én forespørsel
Onboardingkontroller hviler sjelden på ett enkelt dokument. En verifikator kan kreve ett legitimasjonsbevis og godta ett av to andre i tillegg, alt i én forespørsel, slik at innehaveren godkjenner én gang og verifikatoren får et fullstendig svar i ett steg.
Påkrevd
Foretaksregistrering
Én av
MVA-registrering
Én av
Bekreftelse av bankkonto
En firmaregistrering er påkrevd. I tillegg holder det med enten en momsregistrering eller en bankkontoattest, og innehaveren trenger bare å ha én av dem.
Å godta bare tiltrodde utstedere
En verifikator kan snevre inn en forespørsel til legitimasjonsbevis der utstederen står på en offisiell tiltrodd liste. Legitimasjonsbevis fra andre tilbys aldri innehaveren i det hele tatt, så en selvutstedt etterligning når ikke frem til kontrollen i utgangspunktet.
Verifikatoren sier: bare fra utstedere på en offisiell EU-liste over tiltrodde utstedere
Registreringsbevis fra en oppført utsteder
Utstederen står på den tiltrodde listen
✓ Tilbys innehaveren
Registreringsbevis fra en ikke-oppført utsteder
Utstederen står ikke på den tiltrodde listen
✗ Tilbys ikke innehaveren
Dette er et filter i lommeboken, ikke en garanti i seg selv. Verifikatoren sjekker fortsatt utstederen mot den tiltrodde listen når den validerer det den mottok.
Hvor DCQL står i dag
- DCQL er en del av selve OpenID4VP-spesifikasjonen og ikke et eget dokument, og det erstattet en tidligere avhengighet av DIF Presentation Exchange.
- EUDI Wallet Architecture and Reference Framework utpeker OpenID4VP som fremvisningsprotokoll og DCQL sammen med den, så lommebøker og verifikatorer i økosystemet forventes å støtte det.
- Referanselommebøkene og verifikatorene i EUDI Wallet-programmet har samlet seg om DCQL, så en integrasjon mot en forretningslommebok som starter i dag bør legge det til grunn fremfor det eldre alternativet.
Hva dette betyr for deg
Verifikator
Ett forespørselsformat dekker alle lommebøker, og du mottar bare opplysningene du ba om, altså mindre data å lagre, sikre og begrunne.
Innehaver
Du ser nøyaktig hva det spørres om før du godkjenner, og ingenting utover det forlater lommeboken din.
Utsteder
Legitimasjonsbevis du utsteder forblir nyttige for delvise kontroller, så ett bevis kan tjene mange ulike formål.
Teknisk fordypning
Denne siden forklarer hva teknologien gjør og hvem den berører. Utviklerdokumentasjonen vår dekker selve implementeringen: meldingene, feltene og de gjennomarbeidede eksemplene et integrasjonsteam trenger.
Les den tekniske dokumentasjonenRelaterte begreper
Ofte stilte spørsmål
Hvordan skiller DCQL seg fra DIF Presentation Exchange?
Begge er måter for en verifikator å beskrive hva den vil ha fra en lommebok. Presentation Exchange er den eldste og bredeste av de to, laget for å fungere på tvers av flere protokoller. DCQL er bevisst mindre og er definert inne i selve OpenID4VP. EUDI Wallet-økosystemet har standardisert på DCQL, så det er den man bør planlegge etter for det europeiske markedet.
Kan én forespørsel be om mer enn ett legitimasjonsbevis?
Ja, og det er en av grunnene til at det finnes. En verifikator kan be om en firmaregistrering og en bankkontoattest i én og samme forespørsel, eller godta ett av to alternativer, og innehaveren godkjenner alt i ett steg i stedet for å bli spurt to ganger.
Hva skjer hvis innehaveren ikke har alt det ble spurt om?
Verifikatoren kan angi akseptable reservealternativer, i prioritert rekkefølge, og lommeboken bruker det beste innehaveren faktisk kan oppfylle. Slik kan en verifikator be om et presist organisasjonsnummer der det finnes og nøye seg med det juridiske navnet der det ikke finnes, uten å sende en ny forespørsel eller avvise innehaveren.
Er DCQL spesifikt for EUDI Wallet?
Nei. DCQL er en del av OpenID4VP, og enhver implementering av den protokollen kan bruke det. EUDI Wallet-økosystemet er en fremtredende bruker: Architecture and Reference Framework utpeker OpenID4VP med DCQL som måten legitimasjonsbevis fremvises på, og derfor betyr det noe for alle som bygger for det europeiske markedet.
Hjelper dette med dataminimering etter GDPR?
Det gjør minimumet eksplisitt. Forespørselen sier hvilke opplysninger som trengs, innehaveren ser listen før godkjenning, og lommeboken gir ikke fra seg noe utover den. Dermed går dataminimering fra å være noe du lover, til å være en grense selve utvekslingen håndhever, noe som er langt lettere å dokumentere.
Kilder
Denne siden er kun til informasjon og utgjør ikke juridisk rådgivning. For autoritativ veiledning, kontakt OpenID Foundation og Europakommisjonen direkte.