Hvad er en afhængig part i EUDI Wallet-økosystemet?
En afhængig part er enhver organisation, der beder en person eller en virksomhed om dokumentation for noget og derefter læner sig op ad svaret, når den træffer en beslutning. I European Digital Identity Wallet-økosystemet er det parten i den modtagende ende: den anmoder om data fra en tegnebog, kontrollerer dem og handler på resultatet. Den officielle betegnelse er wallet-relying party, og i daglig tale siger de fleste blot verifikator.
Rollen i klart sprog
Rollen er ikke ny. Din organisation er allerede en afhængig part, hver gang den kontrollerer et pas, en virksomhedsudskrift eller et eksamensbevis. Det, der ændrer sig, er, at kontrollen holder op med at være et menneske, der læser et dokument, og bliver et automatisk svar, du kan stole på på sekunder.
Afhængig part er en rolle, ikke en type virksomhed. Den samme organisation kan være afhængig part i én proces og udsteder i en anden: et universitet beder en studerende om et identitetsdokument ved indskrivningen og udleverer et eksamensbevis til sidst. Det, der gør dig til afhængig part i et givent øjeblik, er simpelthen, at det er dig, der spørger, kontrollerer og beslutter.
Det vigtige skifte handler om, hvor beviset kommer fra. I dag er det personen foran dig, der bærer byrden ved at bevise, at et dokument er ægte, og det er dig, der bærer omkostningen ved at vurdere det. Med en tegnebog er beviset signeret af den organisation, der allerede har oplysningen, så kontrollen bliver en udregning i stedet for et skøn.
Derfor er rollen værd at forstå, selv om intet endnu forpligter dig til at påtage dig den. Så snart en kunde kan dokumentere, hvem vedkommende er, på få sekunder, begynder enhver proces, der stadig beder om en upload og en manuel gennemgang, at virke langsom til sammenligning.
Tre hverdagseksempler
Mønstret er altid det samme. Nogen har brug for at kende et faktum, en anden har det allerede, og indtil nu var den eneste måde at bygge bro mellem de to et dokument og en vis grad af tillid.
En bank, der onboarder en kunde
I stedet for at indsamle scanninger af et pas og en registreringsudskrift beder banken om de identitets- og virksomhedsdata, den har brug for, og får et kontrolleret svar på sekunder. Banken er den afhængige part: den handler på data, som en anden har indestået for.
En webshop, der kontrollerer alder
Butikken har brug for ét faktum: er denne kunde gammel nok. Den beder kun om det ene faktum, ikke om en fødselsdato og ikke om en kopi af et dokument, og opbevarer aldrig et identitetsdokument, som den ikke ønskede sig til at begynde med.
En leverandørportal, der kontrollerer en virksomhed
En køber vil vide, at den leverandør, der tilmelder sig, er en reel, registreret virksomhed, og at den person, der tilmelder sig, må handle på dens vegne. Begge fakta kommer fra kilderegistrene i stedet for fra en PDF, som leverandøren har uploadet.
Det, de tre har til fælles, er, at ingen af dem egentlig vil have dokumentet. Banken vil vide, at en virksomhed findes, og at den person, der underskriver, må handle på dens vegne, og butikken vil kun vide, at en kunde er gammel nok. Dokumentet var aldrig pointen, det var bare den eneste tilgængelige bærer af oplysningen.
At skille oplysningen fra dokumentet ændrer, hvad du sidder tilbage med. En alderskontrol, der svarer ja eller nej, efterlader dig uden noget følsomt at beskytte, mens et indscannet pas i et billetsystem er et ansvar, du skal sikre, begrunde og til sidst slette.
Hvad brugeren ser, når du spørger
Når din tjeneste beder om data, ankommer anmodningen ikke i stilhed. Tegnebogen åbner et skærmbillede, der navngiver den organisation, der spørger, viser præcis hvilke data der bliver bedt om, og angiver det formål, organisationen har registreret for dem. Intet deles, før personen trykker for at godkende.
Navnet på det skærmbillede er ikke noget, du selv skriver ind. Det kommer fra det certifikat, du fik, da du registrerede dig, og derfor kan tegnebogen vise det som et kontrolleret faktum frem for en påstand. En anmodning fra en uregistreret aktør kan slet ikke frembringe det skærmbillede.
Personen kan sige nej, og kan sige nej hver gang frem for én gang for alle. Tegnebøger fører også historik over, hvad der er delt, og med hvem, så beslutningen kan gennemses bagefter i stedet for at forsvinde i en indbakke. Samtykke holder op med at være et flueben og bliver noget, brugeren rent faktisk kan efterse.
For din organisation er det hele pointen. Det velkendte bedrageri, en overbevisende side der beder om en kopi af et pas, holder op med at virke, når folk er vant til at se et kontrolleret navn, før de deler noget som helst. At spørge gennem tegnebogen placerer dig på den betroede side af den vane, og anmodninger, der ser legitime ud, bliver oftere gennemført.
Derfor kontrollerer tegnebogen, hvem der spørger
En tegnebog fuld af verificerede identitetsdata er kun sikker, hvis den er kræsen med, hvem den taler med. Hvis et hvilket som helst websted kunne stille den et spørgsmål, ville tegnebogen bare være en hurtigere måde at udlevere identitetsdokumenter til den, der spurgte mest overbevisende. Derfor tager designet udgangspunkt i den modsatte antagelse: en ukendt part får ingenting.
Det er det, registrering og certifikater er til for. Når du registrerer dig som afhængig part, får du certifikater, der identificerer din organisation, og hver medlemsstat offentliggør lister over de myndigheder, der udsteder dem. Tegnebogen kontrollerer certifikatet mod de offentliggjorte lister, før den viser brugeren noget som helst.
Du behøver ikke at følge med i kryptografien for at planlægge efter det her, men du skal planlægge efter konsekvenserne. Certifikater udløber og skal fornyes, tillidslister ændrer sig, efterhånden som myndigheder kommer til eller falder fra, og en anmodning, der er lavet med noget forældet, fejler simpelthen. Det minder mere om at holde en bevilling gyldig end om at skrive software.
Det samme maskineri arbejder til din fordel. Fordi kontrollen sker mod offentliggjorte lister frem for mod en privat aftale, kan en tegnebog udstedt i en anden medlemsstat vurdere din anmodning, uden at du først har aftalt noget med det land. Det er det, der gør én enkelt registrering brugbar i hele Unionen.
Hvem skal acceptere tegnebogen, og fra hvornår
eIDAS 2.0, forordningen der skabte European Digital Identity Wallet, overlader ikke accepten helt til markedet. Medlemsstaterne stiller deres tegnebøger til rådighed fra udgangen af 2026, og en defineret gruppe organisationer skal være klar til at acceptere dem et år senere.
Regulerede sektorer
Hvor EU-retten eller national ret allerede kræver stærk brugerautentifikation, skal tegnebogen accepteres: bank og finans, telekommunikation, energi, transport, sundhed, uddannelse, social sikring, drikkevand, posttjenester og digital infrastruktur. Mikrovirksomheder og små virksomheder er undtaget fra den forpligtelse. Offentlige organer er omfattet af en særskilt regel, overalt hvor de kræver elektronisk identifikation til en onlinetjeneste.
Meget store onlineplatforme
Platforme, der er udpeget som meget store under Digital Services Act, skal acceptere tegnebogen og lette brugen af den, når en bruger beder om det. De må kun bede om de minimale data, tjenesten reelt har brug for.
I praksis er listen mindre abstrakt, end den lyder. Den rammer detailbanker, betalingsinstitutter og forsikringsselskaber, mobiloperatører der opretter abonnenter, energi- og vandleverandører, flyselskaber og togoperatører, hospitaler, apoteker og sundhedsforsikringer, universiteter og eksamensinstanser, og de offentlige myndigheder, der allerede driver et nationalt login. Hvis din onboarding i dag involverer et identitetsdokument, fordi en regel kræver det, er du næsten med sikkerhed omfattet.
At acceptere tegnebogen betyder ikke, at du skal udskifte det, du har. Det betyder, at du tilbyder tegnebogen som en af de måder, en person kan identificere sig på dér, hvor du allerede beder om stærk identifikation, ved siden af de metoder, du understøtter i dag. Eksisterende kunder beholder deres vej ind, og nye får en hurtigere.
Datoerne er værd at skrive ned. Medlemsstaterne udsteder deres tegnebøger fra udgangen af 2026, reglerne om registrering som afhængig part gælder fra december 2026, og pligten til at acceptere tegnebogen kommer ved udgangen af 2027. Registreringen afhænger af en national myndighed og af interne beslutninger om, hvilke data du har brug for, så kalenderen er strammere, end en enkelt dato i 2027 antyder.
Alle andre må acceptere tegnebogen frivilligt, og det vil rigtig mange gøre. Når en kunde allerede har verificerede identitets- og virksomhedsdata med sig, er det et skridt tilbage at bede vedkommende uploade en scanning i stedet, og det vil kunden bemærke.
Hvad en organisation reelt skal have på plads
At blive en afhængig part er mere end at tilføje en knap til en formular. Fire ting skal være på plads, og kun den sidste af dem er rent teknisk.
Registrer dig i dit eget land
Hver medlemsstat fører et offentligt register over de afhængige parter, der er etableret på dens område. Du oplyser, hvem du er, hvad du vil bruge tegnebogen til, og hvilke data du har til hensigt at bede om. Det er ikke tilladt at bede om mere, end du har registreret.
Få dine certifikater
Registreringen giver dig certifikater, som gør, at en tegnebog kan genkende dig. Det er dem, der gør en anonym anmodning til en anmodning, som tegnebogen kan vise brugeren som kommende fra en navngiven, registreret organisation.
Fungere sammen med alle nationale tegnebøger
Der findes ikke én samlet europæisk tegnebogsapp. Hver medlemsstat stiller mindst én til rådighed, så du kobler dig til et felt af tegnebøger og ikke til én. Standarderne er fælles, men hver tegnebog har sine egne tillidsankre og sin egen udgivelsesplan at følge med i.
Kontrollér, at data stadig er gyldige
En credential, der var korrekt sidste måned, kan være tilbagekaldt siden. En afhængig part skal kontrollere en credentials offentliggjorte status på det tidspunkt, den bruges. At føre din egen registrering af den kontrol er god praksis og ikke et krav, men det er det, der senere lader dig vise, at den fandt sted.
Rækkefølgen på den liste betyder mere end dens længde. De to første trin er administrative og kører i en national myndigheds tempo, så det er dem, der afgør, hvornår du kan gå i luften. Teams, der begynder med integrationen og udskyder registreringen, plejer at blive færdige med softwaren og derefter vente.
At beslutte, hvilke data du har brug for, er også et forretningsspørgsmål snarere end et teknisk, og det er værd at besvare omhyggeligt. Du registrerer et formål og et sæt data: at indsnævre det sæt tidligt koster ét møde, mens det at udvide det senere betyder en tur tilbage til registret.
Prisen for at koble sig på mere end tredive tegnebøger
Der findes ikke én samlet europæisk tegnebogsapp. Hver medlemsstat stiller mindst én til rådighed, nogle får flere, og dine kunder møder op med den, deres eget land har udstedt. En organisation med kunder i en håndfuld lande integrerer derfor ikke med én modpart, men med et sæt modparter i bevægelse.
Standarderne nedenunder er fælles, og det er det, der overhovedet gør det muligt. Det, der er forskelligt, er alt rundt om dem: hver tegnebog har sine egne tillidsankre, sin egen nationale profil, sit eget testmiljø og sin egen udgivelseskalender. At bestå en test med én tegnebog siger meget lidt om den næste.
Den første integration er sjældent den dyre. Omkostningen ligger i årene efter: at følge opdateringer af specifikationerne, at teste igen når en national tegnebog udsender en ny version, at holde øje med ændringer i tillidslisterne og at holde certifikaterne gyldige i hvert land, hvor du er etableret. Det er en driftspost i budgettet, ikke en projektpost.
En enkel måde at sætte størrelse på det er at tælle to ting: antallet af medlemsstater, dine kunder kommer fra, og antallet af udgivelser, hver af de tegnebøger sandsynligvis sender ud på et år. Gang dem sammen, så har du antallet af gange, nogen på dit team skal stoppe det, de er i gang med. Det er det tal, og ikke den første udvikling, som beslutningen om at bygge eller købe reelt hviler på.
Byg det selv, eller brug en tjeneste
De fire krav ovenfor kan opfyldes internt eller købes ind. Ingen af svarene er forkerte, men de koster forskellige ting, og forskellen handler mest om, hvem der bærer det løbende arbejde.
Gøre det selv
- Du står selv for registreringen, certifikaterne og fornyelsen af dem i hvert land, hvor du er etableret.
- Dit team følger standarderne og tillidslisterne, efterhånden som de ændrer sig, og leverer en opdatering, hver gang en national tegnebog gør det.
- Intet forlader din infrastruktur, hvilket er det stærkest mulige svar på et databeskyttelsesspørgsmål.
- Det er en løbende teknisk forpligtelse, ikke et projekt, der bliver færdigt.
Bruge en verifikationstjeneste
- Én integration dækker alle tegnebøger, og tilslutningsarbejdet bliver hos leverandøren.
- Ændringer i standarderne, opdateringer af tillidslisterne og statuskontrol håndteres for dig.
- Du går i luften på uger i stedet for kvartaler, og dit team bliver på jeres eget produkt.
- Kør den on-premise, så bliver data inde i din egen infrastruktur, præcis som de ville, hvis du selv havde bygget den.
- Du bliver afhængig af en leverandør, så leverandørens oppetid, udgivelsestakt og behandlingsvilkår bliver dit anliggende.
Det stærkeste argument for at bygge det selv er som regel, at intet forlader din infrastruktur, hvilket er det reneste mulige svar på et databeskyttelsesspørgsmål. Det svar er dog ikke forbeholdt dem, der bygger selv. Den samme verifikationssoftware installeret on-premise, inde i dit eget miljø, holder data præcis dér, hvor de alligevel skulle blive, mens leverandøren stadig bærer arbejdet med standarderne og forbindelserne til de nationale tegnebøger.
En brugbar måde at træffe beslutningen på er at spørge, hvilken branche du er i. Hvis verifikation mod tegnebøger er en del af det, du sælger, giver det mening at eje det fra ende til anden. Hvis det er et trin inde i en onboarding, et login eller en betaling, så er det basisinfrastruktur, og basisinfrastruktur er værd at købe hos nogen, der vedligeholder den til daglig.
Sådan vælger du en verifikationstjeneste
Hvis du beslutter dig for at købe frem for at bygge, handler de spørgsmål, der er værd at stille, mindre om funktioner og mere om, hvor ansvaret ligger, og hvad der sker, når noget ændrer sig. Disse otte er dem, der skiller tilbud, som ligner hinanden på et slide.
- Hvem er registreret som afhængig part? Det bør være din organisation, i dit eget navn, så det erklærede formål er dit og forbliver dit, hvis du skifter leverandør.
- Hvilke nationale tegnebøger og hvilke medlemsstater er dækket i dag, i modsætning til hvad der er lovet på en køreplan?
- Kan den køre både on-premise og som hostet tjeneste, og hvis den hostes, i hvilket land behandles data så?
- Hvad gemmes, hvor længe, og hvad sidder du tilbage med som dokumentation for, at en kontrol fandt sted?
- Hvordan kontrolleres tilbagekaldelse og gyldighed i brugsøjeblikket frem for én gang ved opsætningen?
- Hvem bærer omkostningen, når en standard, en tillidsliste eller en national tegnebog ændrer sig, og hvor hurtigt?
- Findes der et testmiljø, hvor du kan prøve et rigtigt flow, før du binder dig til noget?
- Hvordan ville du komme væk igen? Data, der kan eksporteres, og en registrering i dit eget navn er det, der gør det muligt.
Det første spørgsmål er det, du skal holde fast i. Hvis registreringen står i dit eget navn, beholder du forholdet til registret, det erklærede formål og muligheden for at skifte leverandør uden at begynde forfra. Alt andet på listen kan forhandles, og netop det punkt kan virkelig ikke.
Kom i gang: use case, pilot, tidsplan
Start med ét use case, og vælg det snævreste af dem, der koster dig noget målbart i dag. En alderskontrol, en virksomhedskontrol når en leverandør tilmelder sig, eller identitetstrinnet i en kontoåbning er alle små nok til at blive færdige og specifikke nok til at bevise en pointe. Et program, der skal modernisere al identitet alle steder, er ikke et første projekt.
Kør piloten ved siden af din nuværende proces frem for at erstatte den. Tilbyd tegnebogen som en ekstra vej for en del af trafikken, hold den gamle vej åben, og sammenlign de to på de tal, du allerede følger: hvor lang tid det tager, hvor mange der bliver færdige, og hvor meget manuel gennemgang der er tilbage. Det er den sammenligning, der skaber forretningsgrundlaget, ikke en demonstration.
Sæt registreringen i gang tidligt, for det er den del, du styrer mindst. Den afhænger af en national myndighed og af en intern beslutning om, hvilke data du reelt har brug for, og begge dele tager længere tid, end de ser ud til. Den tekniske integration er som regel den korteste halvdel af arbejdet, især hvis du ikke selv bygger forbindelserne til tegnebøgerne.
Et realistisk forløb for en organisation, der begynder nu, er en beslutning og en registrering i første kvartal, en fungerende pilot i andet og en gradvis udrulning derefter, hvilket giver luft før pligten i 2027 frem for at nå den lige på stregen. Hvis pligten ikke gælder dig, holder den samme rækkefølge alligevel, bare med den forskel at fristen sættes af dine konkurrenter i stedet for af forordningen.
Sådan hjælper Credenco
Credenco driver siden som afhængig part for dig, mens du beholder beslutningen. Du forbliver den registrerede organisation, og du beholder data, og tilslutningsarbejdet mod tegnebøgerne ligger hos os.
Verification Service
Bed om præcis de data, du har brug for, og få et kontrolleret svar tilbage. Signaturer, tillidslister og tilbagekaldelsesstatus håndteres bag én integration, så det at være afhængig part ikke bliver til et protokolprojekt.
Business Wallet
Din organisation har også sine egne beviser at modtage og fremvise, for eksempel når en kunde eller en køber beder dig dokumentere noget. En Business Wallet er en tjeneste, som dine systemer styrer, ikke en app, som nogen skal åbne.
Begge kører som en hostet tjeneste eller on-premise i dit eget miljø, så driftsmodellen er en beslutning, du træffer, og ikke en, produktet træffer for dig. Uanset hvad står registreringen i dit navn, og tegnebogen viser din organisation til brugeren.
Ofte stillede spørgsmål
Hvad er en afhængig part, sagt ligeud?
Det er enhver organisation, der beder nogen om dokumentation og derefter handler på svaret. En bank, en webshop, en arbejdsgiver og en offentlig skranke er alle afhængige parter. I EUDI Wallet-økosystemet kommer dokumentationen fra en tegnebog og kan kontrolleres automatisk, så organisationen læner sig op ad kontrollen i stedet for et dokument, den skal tro på.
Skal min organisation acceptere EUDI Wallet?
Ja, hvis EU-retten eller national ret allerede forpligter dig til at autentificere brugere stærkt. Det omfatter sektorer som bank og finans, telekommunikation, energi, transport, sundhed, uddannelse, social sikring, posttjenester og digital infrastruktur, og også hvis du er en meget stor onlineplatform udpeget under Digital Services Act. Mikrovirksomheder og små virksomheder er undtaget fra den sektorforpligtelse. Alle andre må acceptere tegnebogen frivilligt, og mange vil gøre det, fordi kunder med en tegnebog forventer at kunne bruge den.
Skal vi også udstede beviser?
Nej. At modtage beviser og at udstede dem er to adskilte roller, og de fleste organisationer får kun brug for den første. Verifikation er den mindste opgave: du beder om data, kontrollerer dem mod en offentliggjort tillidsliste og læser svaret, uden den identitetskontrol og nøglehåndtering, en udsteder påtager sig.
Må vi bede om lige de data, vi vil have?
Nej, og det er med vilje. Du registrerer de data, du har brug for, og det formål, du skal bruge dem til, og en anmodning uden for det omfang kan afvises. I praksis skubber det organisationer mod at bede om mindre, hvilket databeskyttelsesretten også har bedt om hele tiden.
Hvornår bør vi gå i gang?
Hvis accepten er obligatorisk for dig, er fristen udgangen af 2027, og registrering, indkøb og test ligger alle foran den. Hvis den ikke gælder for dig, er der stadig grund til at komme i gang: en onboarding, der tager sekunder i stedet for dage, er værd at have, uanset om en forordning beder om det eller ej.
Relaterede begreber
Teknisk dybdegang
Denne side holder sig på niveauet for, hvad rollen betyder for din organisation. Hvordan en anmodning rent faktisk sættes sammen og besvares, over OpenID4VP-protokollen, er dækket i den tekniske dokumentation. Læs den tekniske dokumentation
Denne side er til orientering og udgør ikke juridisk rådgivning. For autoritativ vejledning om, hvorvidt en forpligtelse gælder for din organisation, bør du kontakte Europa-Kommissionen og din nationale tilsynsmyndighed direkte.