DCQL forklaret: sådan beder en verifier en wallet om præcis det, den har brug for
DCQL, Digital Credentials Query Language, er den aftalte måde, hvorpå en organisation fortæller en tegnebog, hvilke legitimationsbeviser den har brug for, og hvilke oplysninger inde i dem. Det er det, der gør en anmodning som "bevis, at din virksomhed er registreret i Nederlandene" til noget, enhver kompatibel tegnebog forstår, uden en særskilt integration pr. tegnebog.
Problemet, DCQL løser
En forretningstegnebog indeholder legitimationsbeviser af mange slags, udstedt af forskellige organer i forskellige lande og gemt i forskellige tekniske formater. En organisation, der kun har brug for at bekræfte et registreringsnummer og et juridisk navn, har ingen portabel måde at bede om præcis det. Den ender enten med at tage hele beviset, med alt det andet i det, eller med at bygge en særskilt integration til hver tegnebog, den møder.
DCQL løser spørgesiden. Én standardanmodning angiver de ønskede legitimationsbeviser og de bestemte oplysninger, der ønskes fra hvert af dem. Tegnebogen holder den op mod det, indehaveren faktisk har, viser indehaveren, hvad der bliver bedt om, og udleverer kun det. Verifikatoren får et forudsigeligt svar, uanset hvilken tegnebog indehaveren bruger.
1. Verifier
Beder om præcis de legitimationsbeviser og oplysninger, den har brug for
2. Wallet
Finder ud af, hvilke af de gemte legitimationsbeviser der passer til anmodningen
3. Indehaver
Ser, hvad der bliver bedt om, og godkender, at kun det udleveres
4. Verifier
Modtager de godkendte oplysninger og intet mere
Hvad en verifikator kan bede om
En anmodning er en kort liste over, hvad der er brug for. Den kan angive ét legitimationsbevis eller flere, og for hvert af dem kan den angive de bestemte oplysninger, der ønskes, i stedet for hele beviset. Tre muligheder oveni dækker næsten alle virkelige tilfælde: alternativer, kombinationer og en grænse for, hvilke udstedere der accepteres.
- Hvilke legitimationsbeviser der er brug for, og hvilke oplysninger inde i hvert af dem.
- Acceptable alternativer, i prioriteret rækkefølge, til indehavere, der ikke har det hele.
- Kombinationer, så en anmodning kan kræve ét legitimationsbevis og et af to andre.
- En begrænsning til udstedere på en officiel betroet liste, så legitimationsbeviser fra andre aldrig tilbydes.
At bede om et alternativ
Ikke alle indehavere har det samme legitimationsbevis. En verifikator kan angive, hvad den helst vil have, og hvad den stadig vil acceptere, i prioriteret rækkefølge, og tegnebogen bruger den bedste mulighed, indehaveren faktisk kan opfylde. Det sparer en ekstra runde og forhindrer, at en kunde bliver afvist, blot fordi en detalje, det var rart at have, mangler.
1. Foretrukket
Bruges, når legitimationsbeviset indeholder begge
2. Alternativ
Bruges kun, når den første mulighed ikke kan opfyldes
Her vil verifikatoren helst have et registreringsnummer sammen med det juridiske navn, men accepterer det juridiske navn alene, når indehaverens legitimationsbevis ikke indeholder et registreringsnummer.
At kombinere legitimationsbeviser i én anmodning
Onboardingkontroller hviler sjældent på ét enkelt dokument. En verifikator kan kræve ét legitimationsbevis og acceptere et af to andre ved siden af, alt sammen i én anmodning, så indehaveren godkender én gang, og verifikatoren får et fuldstændigt svar i ét trin.
Påkrævet
Virksomhedsregistrering
En af
Momsregistrering
En af
Attestering af bankkonto
En virksomhedsregistrering er påkrævet. Derudover er enten en momsregistrering eller en bankkontoattest nok, og indehaveren skal kun have en af dem.
Kun at acceptere betroede udstedere
En verifikator kan indsnævre en anmodning til legitimationsbeviser, hvor udstederen står på en officiel betroet liste. Legitimationsbeviser fra andre bliver aldrig overhovedet tilbudt indehaveren, så en selvudstedt efterligning når slet ikke frem til kontrollen.
Verifikatoren siger: kun fra udstedere på en officiel EU-liste over betroede udstedere
Registreringscredential fra en listet udsteder
Udstederen står på den betroede liste
✓ Tilbydes indehaveren
Registreringscredential fra en ikke-listet udsteder
Udstederen står ikke på den betroede liste
✗ Tilbydes ikke indehaveren
Det er et filter i tegnebogen, ikke en garanti i sig selv. Verifikatoren kontrollerer stadig udstederen mod den betroede liste, når den validerer det, den har modtaget.
Hvor DCQL står i dag
- DCQL er en del af selve OpenID4VP-specifikationen og ikke et særskilt dokument, og det erstattede en tidligere afhængighed af DIF Presentation Exchange.
- EUDI Wallet Architecture and Reference Framework udpeger OpenID4VP som fremvisningsprotokol og DCQL sammen med den, så tegnebøger og verifikatorer i økosystemet forventes at understøtte det.
- Referencetegnebøgerne og verifikatorerne i EUDI Wallet-programmet er samlet om DCQL, så en integration til en forretningstegnebog, der påbegyndes i dag, bør lægge det til grund frem for det ældre alternativ.
Hvad det betyder for dig
Verifier
Ét anmodningsformat dækker alle tegnebøger, og du modtager kun de oplysninger, du bad om, altså færre data at gemme, sikre og begrunde.
Indehaver
Du ser præcis, hvad der bliver bedt om, før du godkender, og intet derudover forlader din tegnebog.
Udsteder
De legitimationsbeviser, du udsteder, forbliver brugbare til delvise kontroller, så ét bevis kan tjene mange forskellige formål.
Teknisk fordybelse
Denne side forklarer, hvad teknologien gør, og hvem den berører. Vores udviklerdokumentation dækker selve implementeringen: meddelelserne, felterne og de gennemarbejdede eksempler, et integrationsteam har brug for.
Læs den tekniske dokumentationRelaterede begreber
Ofte stillede spørgsmål
Hvordan adskiller DCQL sig fra DIF Presentation Exchange?
Begge er måder, hvorpå en verifikator kan beskrive, hvad den vil have fra en tegnebog. Presentation Exchange er den ældste og bredeste af de to og er lavet til at fungere på tværs af flere protokoller. DCQL er bevidst mindre og er defineret inde i selve OpenID4VP. EUDI Wallet-økosystemet har standardiseret på DCQL, så det er den, man bør planlægge efter til det europæiske marked.
Kan én anmodning bede om mere end ét legitimationsbevis?
Ja, og det er en af grundene til, at det findes. En verifikator kan bede om en virksomhedsregistrering og en bankkontoattest i én og samme anmodning eller acceptere et af to alternativer, og indehaveren godkender det hele i ét trin i stedet for at blive spurgt to gange.
Hvad sker der, hvis indehaveren ikke har alt det, der blev bedt om?
Verifikatoren kan angive acceptable alternativer, i prioriteret rækkefølge, og tegnebogen bruger det bedste, indehaveren faktisk kan opfylde. Sådan kan en verifikator bede om et præcist registreringsnummer, hvor det findes, og nøjes med det juridiske navn, hvor det ikke findes, uden at sende en ny anmodning eller afvise indehaveren.
Er DCQL specifikt for EUDI Wallet?
Nej. DCQL er en del af OpenID4VP, og enhver implementering af den protokol kan bruge det. EUDI Wallet-økosystemet er en fremtrædende bruger: Architecture and Reference Framework udpeger OpenID4VP med DCQL som måden, legitimationsbeviser fremvises på, og derfor har det betydning for alle, der bygger til det europæiske marked.
Hjælper det her med dataminimering efter GDPR?
Det gør minimum eksplicit. Anmodningen angiver, hvilke oplysninger der er brug for, indehaveren ser listen før godkendelsen, og tegnebogen udleverer intet derudover. Dermed går dataminimering fra at være noget, du lover, til at være en grænse, som selve udvekslingen håndhæver, og det er langt lettere at dokumentere.
Kilder
Denne side er udelukkende til orientering og udgør ikke juridisk rådgivning. Kontakt OpenID Foundation og Europa-Kommissionen direkte for autoritativ vejledning.