Het formulier is succesvol verzonden.
Meer informatie vindt u in uw mailbox.
Inhuren
Over ons
DienstenTechnologieënIndustrieënPortfolio
Je hebt het waarschijnlijk zelf gezien: geef GPT een selfie, vraag om een paspoortachtig document en binnen een paar minuten krijg je iets dat voorbij de visuele basiscontroles kan komen. Voeg daar stem klonen en synthetische video aan toe en “echtheid” begint op theater te lijken. Dat is de echte doorbraak in digitale identiteit in 2026. Het op foto's gebaseerde KYC-model zelf is aan het verslijten. Als het identiteitsbewijs nog steeds afhankelijk is van afbeeldingen die moeilijk te vervalsen zijn, dan bouw je op zand.
Waar staan we nu? Met een vrij voor de hand liggende verschuiving: weg van het opslaan van identiteitsgegevens en naar het cryptografisch verifiëren van claims. In plaats van een paspoortscan te verzamelen en die in een andere database te parkeren, vraagt het systeem om bewijs: ben je ouder dan 18, ben je geslaagd voor KYC, ben je goedgekeurd voor deze transactie, en kun je het bewijzen zonder iets anders te onthullen?
Maar wat verandert er precies? Waarom hebben we het opeens over DID's en verifieerbare geloofsbrieven?
Omdat in een op DID gebaseerd model vertrouwen niet afhangt van hoe iets eruit ziet. Het gaat erom wie het ondertekend heeft en of je kunt aantonen dat je er controle over hebt. Een deepfake selfie helpt niet als de verificateur een geloofsbrief verwacht die is ondertekend door een vertrouwde uitgever en is gekoppeld aan jouw cryptografische sleutels. Je probeert niet langer “er echt uit te zien”. Je bewijst het bezit van een geldige, ondertekende claim. Afbeeldingen zijn niet langer de bron van vertrouwen. Handtekeningen nemen het over.
En dat is het doel van deze gids: Ik laat zien hoe dat model werkt, waarom het de serieuze weg vooruit aan het worden is en waar blockchain in past.
Een gedecentraliseerde identifier, of DID, is een URI-gebaseerde identifier die ontworpen is om gecontroleerd te worden door middel van cryptografische sleutels in plaats van uitgegeven en beheerd te worden door een centrale directory. Onder de World Wide Web Consortium (W3C) In de DID-standaard verwijst een DID naar een DID-document dat andere systemen informeert over hoe ze handtekeningen kunnen verifiëren, de controller kunnen authenticeren of service-eindpunten kunnen ontdekken die aan die identifier zijn gekoppeld. In gewoon Engels: een DID is niet je profiel, je paspoort of je accountrecord. Het is de aanwijzer die andere partijen gebruiken om te verifiëren dat je een specifieke identifier en de achterliggende sleutels beheert.
Dit is waar mensen vaak alles afvlakken tot “gewoon weer een ID”. Dat is het niet.
Een e-mailadres is echt een locator binnen het systeem van iemand anders. Als de provider de account opschort, is de identificatie effectief verdwenen. Een SSN is een door de staat uitgegeven identifier, maar het heeft geen ingebouwde cryptografische bewijslaag; iedereen die het nummer krijgt kan het opnieuw spelen. OAuth tokens zijn weer anders: het zijn helemaal geen identiteitsidentifiers, maar gedelegeerde toegangsartefacten uitgegeven door een autorisatieserver zodat een client een beschermde bron kan oproepen. Nuttig, ja. Draagbare identiteitslaag, nee.
Een DID werkt anders. Het is de bedoeling dat het wordt opgelost, niet dat het alleen maar wordt opgezocht in een leveranciersdatabase. De controle ligt bij het onderwerp door middel van sleutelmateriaal en de regels van de DID-methode, niet bij een mailprovider, SaaS-platform of identity broker. Dat onderscheid is belangrijk in de praktijk. Als je herbruikbare referenties, op portemonnee gebaseerde aanmeldingen of verificatiestromen maakt die over organisatiegrenzen heen moeten werken, zal een e-mail- of app-specifieke gebruikers-ID niet genoeg vertrouwen uitstralen. Een DID kan dat wel.
Op syntax-niveau is het W3C-model eenvoudig: een DID bestaat uit drie delen: het DID-schema, een methode-naam en een methode-specifieke identifier. Met andere woorden: did:methode:identificator.
Neem did:web:example.com als concreet voorbeeld.
Met deed:web, De resolutie wordt meestal gekoppeld aan een DID-document dat is gepubliceerd op een bekende HTTPS-locatie op dat domein. Met iets als deed:ethr, resolutie is afhankelijk van Ethereum-gekoppelde methode regels. Zelfde DID-syntaxis, ander vertrouwens- en updatemodel.
Dat is het belangrijkste punt: de DID-string zelf is slechts het handvat. De methode vertelt je hoe je het moet oplossen. Het DID-document geeft je het verificatiemateriaal. Als je dat eenmaal hebt, kun je handtekeningen verifiëren, een houder authenticeren of een credentialpresentatie valideren. zonder de identifier te behandelen als gewoon een rij in iemands gebruikerstabel.
Tot nu toe hebben we naar DID's en verifieerbare geloofsbrieven gekeken als gegevensstructuren: identifiers, documenten, handtekeningen. Maar dat is slechts een deel van een werkend identiteitssysteem. In echte implementaties is interactie het moeilijkste probleem: hoe referenties worden uitgegeven, hoe ze worden gepresenteerd en hoe verificateurs beslissen of ze ze vertrouwen.
In productiesystemen zoals de EU digitale identiteitsportefeuille of Amerikaans mobiel rijbewijs (mDL) pilots, portemonnees en verificateurs lossen niet zomaar een DID op en stoppen daar. Ze communiceren via gedefinieerde protocollen en formaten voor referenties:
Het belangrijke onderscheid is dat DID's en verifieerbare geloofsbrieven het volgende definiëren wat wordt geverifieerd. Deze protocollen definiëren hoe het beweegt tussen de uitgever, houder en verificateur in echte systemen.
Zonder deze laag blijven DID's een resolutiemechanisme. Met deze laag worden ze onderdeel van een werkende identiteitsinfrastructuur.
Als we het uitpraten, is gedecentraliseerde identiteit een model waarbij identifiers, referenties en verificatiestromen niet worden gecontroleerd door een enkele provider. In plaats daarvan wordt identiteit verankerd in cryptografische sleutels (via DID's) en worden claims over die identiteit uitgegeven en geverifieerd onafhankelijk van waar ze worden gebruikt. Een handige manier om erover na te denken: Identiteit houdt op een account te zijn dat is opgeslagen in de database van iemand anders en wordt een set verifieerbare verklaringen die je controleert en hergebruikt.
Laten we dat eens vergelijken met de modellen waar je al mee werkt.
Gecentraliseerde identiteit is nog steeds overal de standaard. Een platform is eigenaar van het gebruikersrecord, slaat je gegevens op en treedt op als verificatieautoriteit. Als je toegang wilt, authenticeer je je bij dat systeem. Alles, inclusief inloggen, rechten, herstel, verloopt via dat systeem.
Het probleem is niet alleen de beveiliging (hoewel inbreuken een constant probleem zijn). Het is architectuur:
Decentrale identiteit draait dit om. Het systeem hoeft je gegevens niet op te slaan. Het hoeft alleen de claims die je maakt te verifiëren. Het vertrouwen verschuift van “wij hebben uw gegevens” naar “wij kunnen dit cryptografische bewijs verifiëren”.”
Gefedereerde identiteit (OAuth, SAML, OpenID Connect) probeerde fragmentatie op te lossen door identiteitsproviders te introduceren, zoals Google, Microsoft of Apple, die instaan voor gebruikers in verschillende diensten.
Het werkt, tot op zekere hoogte. Maar gefedereerde identiteit heeft nog steeds een centrale afhankelijkheid:
Gedecentraliseerde identiteit neemt die afhankelijkheid weg. Er is niet één uitgever die online moet zijn op het moment van verificatie. Credentials worden geverifieerd via handtekeningen, niet via API-aanroepen. Dat betekent:
Het lijkt meer op hoe fysieke legitimatiebewijzen werken: je belt niet elke keer het paspoortkantoor als iemand je ID controleert.
Deze termen worden vaak door elkaar gebruikt. SSI is meer een ontwerpfilosofie: het individu controleert zijn identiteit, kiest wat hij deelt en zit niet vast aan een provider. Decentrale identiteit is de technische stapel die dat mogelijk maakt:
Je kunt gedecentraliseerde identiteitssystemen implementeren die niet volledig “self-sovereign” zijn (bijvoorbeeld bedrijfsgecontroleerde wallets of netwerken met toestemming). En je kunt over SSI praten zonder de infrastructuur te specificeren. In echte systemen komen de twee meestal samen, maar het is nuttig om het onderscheid duidelijk te houden wanneer je architecturen ontwerpt.
Portemonnees zijn waar gedecentraliseerde identiteit samenkomt met beperkingen uit de echte wereld. In theorie komt controle over identiteit voort uit controle over cryptografische sleutels. In de praktijk creëert dat een probleem dat traditionele systemen niet hebben: Wat gebeurt er als de gebruiker de toegang verliest?
Als een DID gekoppeld is aan een privésleutel en die sleutel gaat verloren, dan is er geen standaard herstelmechanisme. Er is geen “reset wachtwoord” flow tenzij het systeem expliciet ontworpen is om dit te ondersteunen. Verlies van de sleutel kan betekenen dat de controle over de identifier en de daaraan gekoppelde referenties verloren gaat.
Daarom introduceren productiesystemen herstel- en bewaarmodellen bovenop de DID-laag:
De afweging is onvermijdelijk: hoe meer controle verschuift naar de gebruiker, hoe meer verantwoordelijkheid verschuift naar sleutelbeheer. Dat is de reden waarom de meeste implementaties in de echte wereld een balans vinden tussen zelfbeschikking en bruikbaarheid in plaats van het volledige eigenaarschap van de sleutel volledig bij de gebruiker te leggen.
Het is de moeite waard om hier even te pauzeren, omdat identiteit op basis van DID pas echt klikt als je de kernprimitieven scheidt. De identifier is niet de credential, de credential is niet de portemonnee en de on-chain marker is niet de identiteit zelf. Elke laag heeft een aparte functie en die scheiding zorgt ervoor dat het model werkt.
Deze twee componenten vormen de kern van het gedecentraliseerde identiteitsmodel. In sommige systemen, vooral in Web3-omgevingen, worden aanvullende on-chain mechanismen gebruikt om toegang of rollen af te dwingen.
Zielsgebonden lopers (SBT's) zijn daar een voorbeeld van. Het zijn niet-overdraagbare tokens die gebonden zijn aan een portemonnee en gebruikt worden voor zaken als KYC-gating, accreditatie of protocolmachtigingen. Slimme contracten kunnen ze direct controleren.
SBT's maken echter geen deel uit van de identiteitsstapel zelf. Ze zijn een optionele handhavingslaag die bovenop de identiteitssignalen wordt gebouwd en ze hebben nadelen: openbare zichtbaarheid op de keten, beperkte overdraagbaarheid en uitdagingen rond intrekking en sleutelherstel.
Traditionele identiteitssystemen falen omdat ze vertrouwen behandelen als een opslagprobleem. Elk platform verzamelt hetzelfde ruwe bewijsmateriaal, zoals paspoortscans, selfies en adresbewijzen, en slaat dit vervolgens op binnen zijn eigen compliance-perimeter. Dat creëert overal dezelfde puinhoop: dubbele PII, zwakke overdraagbaarheid, brede oppervlakken voor inbreuken en onboardingstromen die steeds zwaarder worden zonder veel beter te worden.
In het traditionele model accumuleren identiteitssystemen het risico in de loop van de tijd. KYC-verkopers, beurzen, fintech apps, HR-platforms en marktplaatsen slaan uiteindelijk allemaal ongeveer hetzelfde bewijsmateriaal op: ID van de overheid, gezichtsscan, adresgegevens en metadata van de verificatiesessie zelf.
Vanuit een implementatiestandpunt wordt het probleem meestal verergerd door de wildgroei aan kopieën. Dezelfde gebruikersgegevens komen terecht in onboardingsystemen, fraudetools, CRM-lagen, supporttools, datawarehouses en compliance-archieven. Zelfs als de primaire verificatiestapel is vergrendeld, worden de omliggende systemen vaak niet aan dezelfde standaard gehouden.
Traditionele identiteit geeft de gebruiker bijna geen controle over de verificatiestatus. Het platform controleert het record, het bewaarbeleid, het herverificatieschema en de regels voor hergebruik.
Dat betekent dat de gebruiker het vertrouwen niet van de ene naar de andere context kan overbrengen. Het slagen voor KYC op Platform A doet niets op Platform B omdat het verificatieresultaat gevangen zit binnen de compliance perimeter van Platform A. De onderliggende claim kan nog steeds geldig zijn, maar er is geen overdraagbaar cryptografisch artefact waarop de volgende verificateur kan vertrouwen. De onderliggende claim kan nog steeds geldig zijn, maar er is geen overdraagbaar cryptografisch artefact waar de volgende verificateur op kan vertrouwen.
Hier begint het model economisch te breken. Elk platform betaalt om het vertrouwen opnieuw op te bouwen, omdat identiteit wordt opgeslagen als interne gegevens en niet wordt uitgegeven als herbruikbaar bewijs.
Het legacy model onthult ook standaard te veel. Om een klein feit te bewijzen, wordt gebruikers meestal gevraagd om het volledige brondocument erachter openbaar te maken.
Dat is een slecht privacypatroon, maar ook een slecht systeempatroon. Als identiteit eenmaal gekoppeld is aan account-gebaseerde records en herhaalde indiening van documenten, dan wordt correlatie eenvoudig tussen diensten, sessies en tegenpartijen. De verificateur krijgt meer gegevens dan hij nodig heeft, slaat meer gegevens op dan hij zou moeten en verhoogt de aansprakelijkheid zonder de kwaliteit van het vertrouwen evenredig te verbeteren.
Dit is de operationele belasting die iedereen al kent. Dezelfde persoon vult KYC keer op keer in omdat elk platform zijn eigen trust stack gebruikt en verificatie niet kan consumeren als een overdraagbaar credential.
Als je hebt gewerkt aan tokenisatie, exchange onboarding of gereguleerde wallet flows, dan heb je gezien hoe verspillend dit kan zijn. De bottleneck is het feit dat vertrouwen niet netjes tussen systemen kan bewegen, dus elke instelling bouwt dezelfde verificatiepijplijn opnieuw op rond zijn eigen databasegrens.
En zelfs verifieerbare geloofsbrieven alleen lossen dat niet op. Een geldige handtekening bewijst alleen dat een claim is uitgegeven door een specifieke partij. Het bewijst niet dat deze partij de autoriteit had om die claim uit te geven. Dat is het deel dat veel DID-piloten onderschatten. Verificateurs moeten weten welke uitgevers legitiem zijn, welke credential schema's geaccepteerd worden en onder welke regels een claim betrouwbaar is.
In productie wordt dit afgehandeld via vertrouwensframeworks: eIDAS 2.0 vertrouwenslijsten in de EU, VICAL-stijl vertrouwenscoördinatie voor mobiele rijbewijzen volgens ISO 18013-5, OpenID Federatie vertrouwensketens en nationale registers van aanbieders van vertrouwensdiensten.
Zonder die laag krijg je geen herbruikbare identiteit. Je krijgt referenties die wiskundig verifiëren maar operationeel niets betekenen. De handtekening is geldig. Het vertrouwen ontbreekt.
"Waarom werkt het gedecentraliseerde identiteitsmodel? Omdat elke partij minder hoeft op te slaan, minder hoeft bloot te geven en minder hoeft te controleren. De gebruiker hergebruikt het vertrouwde bewijs, de verificateur krijgt alleen de claim die hij nodig heeft en het platform vermijdt om nog een PII-kluis te worden. Bij Innowise betekent dat meestal off-chain referenties voor overdraagbaarheid, on-chain attesten voor toegangscontrole en selectieve openbaarmaking voor privacygevoelige controles."
Blockchain expert & DeFi analist
Genoeg over definities. Waar het hier om gaat is het verificatietraject: hoe een DID resolvabel wordt, hoe een uitgever er een claim aan koppelt en hoe die claim later wordt gecontroleerd zonder terug te vallen op een centraal register. Laten we de stroom van begin tot eind doorlopen.
Een DID wordt pas bruikbaar als het opgelost kan worden. Het wordt gegenereerd met sleutelmateriaal en gepubliceerd volgens een DID-methode. Resolutie retourneert het DID-document, dat de openbare sleutels en verificatiemethoden blootlegt die anderen gebruiken om handtekeningen te valideren.
Zodra het subject een DID heeft, kan een uitgever er een ondertekende claim aan koppelen als een verifieerbaar credential. De uitgever voert eerst zijn controles uit en ondertekent dan een geloofsbrief die de claim bindt aan de identificatie van het subject. Wat verder gaat is geen onbewerkt bewijs, maar een geattesteerd resultaat.
De houder bewaart de geloofsbrief, meestal in een portemonnee, en presenteert deze wanneer er een bewijs nodig is. Afhankelijk van de stack kan dat de volledige credential of een afgeleid bewijs zijn. Het punt is hergebruik: de houder presenteert een al geverifieerde claim in plaats van opnieuw te beginnen met onboarding.
De verificateur controleert de handtekening van de uitgever, bevestigt de onderwerpbinding en evalueert de status van het certificaat, zoals verlopen of ingetrokken. Daartoe wordt de DID van de verstrekker opgelost en wordt de openbare sleutel uit het DID-document gehaald. Er is geen callback van de uitgever nodig.
Een DID wordt pas bruikbaar als het opgelost kan worden. Het wordt gegenereerd met sleutelmateriaal en gepubliceerd volgens een DID-methode. Resolutie retourneert het DID-document, dat de openbare sleutels en verificatiemethoden blootlegt die anderen gebruiken om handtekeningen te valideren.
Zodra het subject een DID heeft, kan een uitgever er een ondertekende claim aan koppelen als een verifieerbaar credential. De uitgever voert eerst zijn controles uit en ondertekent dan een geloofsbrief die de claim bindt aan de identificatie van het subject. Wat verder gaat is geen onbewerkt bewijs, maar een geattesteerd resultaat.
De houder bewaart de geloofsbrief, meestal in een portemonnee, en presenteert deze wanneer er een bewijs nodig is. Afhankelijk van de stack kan dat de volledige credential of een afgeleid bewijs zijn. Het punt is hergebruik: de houder presenteert een al geverifieerde claim in plaats van opnieuw te beginnen met onboarding.
De verificateur controleert de handtekening van de uitgever, bevestigt de onderwerpbinding en evalueert de status van het certificaat, zoals verlopen of ingetrokken. Daartoe wordt de DID van de verstrekker opgelost en wordt de openbare sleutel uit het DID-document gehaald. Er is geen callback van de uitgever nodig.
Als de stroom eenmaal duidelijk is, komen de echte ontwerpvragen naar voren: hoe identifiers worden gebruikt en hoe sleutels in de loop van de tijd worden beheerd.
Een openbare DID stabiel en vindbaar is. Uitgevers gebruiken het meestal omdat verificateurs een consistente manier nodig hebben om sleutels om te zetten en handtekeningen te valideren. Een paarsgewijze DID wordt daarentegen per relatie gegenereerd. Dezelfde gebruiker presenteert verschillende identifiers aan verschillende verificateurs, wat dienstoverkoepelende correlatie voorkomt.
Die keuze is niet cosmetisch. Het hergebruik van een enkele DID voor alle diensten maakt koppeling triviaal. Paargewijze DID's verbreken die koppeling op identificatieniveau.
Dan is er nog het sleutelbeheer, waar de meeste systemen in de productie mee worstelen. Een DID is slechts zo betrouwbaar als de sleutels erachter, dus je moet het goed plannen:
In de praktijk zit hier de complexiteit. Handtekeningverificatie is eenvoudig. Identifiers bruikbaar, herstelbaar en niet-correleerbaar houden in de tijd is het moeilijkste technische probleem.
Als je eenmaal voorbij de stroom bent, is de volgende vraag hoe identifiers worden opgelost en onderhouden. Dat komt neer op twee dingen: de DID-documentstructuur en de DID-methode dat bepaalt hoe het wordt gemaakt, bijgewerkt en opgelost.
Een DID-document is de resolutie-uitgang van een DID. Het vertelt verificateurs welke sleutels, controllers en service eindpunten geautoriseerd zijn voor die identifier. In de praktijk is het geen gebruikersprofiel. Het is een verificatiedescriptor.
Kerngebieden waar je meestal om geeft:
En het sleutelimplementatiepunt blijft hetzelfde: een verificateur lost de DID op, selecteert de juiste verificatiemethode en controleert of die sleutel geautoriseerd is voor de bewerking die wordt uitgevoerd.
Tot nu toe hebben we het vooral gehad over identiteit als iets dat een persoon controleert. In B2B-systemen is het belangrijkste onderwerp vaak een organisatie. Banken, logistieke dienstverleners en RWA-platforms moeten niet alleen die iets tekende, maar of die persoon bevoegd was om voor een bedrijf op te treden.
Dat is waar organisatorische DID's complexer worden. Controle is verdeeld over rollen, bewaarsystemen, ondertekeningsbeleid en delegatieregels. Een productieopstelling moet definiëren wie kan ondertekenen, wat ze kunnen ondertekenen en hoe die bevoegdheid wordt ingetrokken.
In de praktijk kan dit het volgende inhouden vLEI van GLEIF voor de identiteit van rechtspersonen, bedrijfsportemonnees met HSM-ondersteunde ondertekening, en autorisatiemogelijkheidsketens zoals ZCAP-LD.
DID-documenten zijn niet statisch. Sleutels verlopen, apparaten raken kwijt, de ondertekeningsinfrastructuur verandert en de sleutels van de uitgever moeten worden geroteerd. Een serieus DID-ontwerp moet hiermee omgaan zonder bestaande referenties te breken.
Sleutelrotatie betekent meestal het toevoegen van een nieuwe verificatiemethode, het veranderen van de sleutel die geautoriseerd is voor een bepaalde relatie en het intrekken van de oude sleutel. Maar het belangrijkste detail is doel. Een authenticatie toets heeft invloed op de aanmeldings- of challenge-response stromen. Het draaien van een beweringMethode sleutel van invloed is op de uitgifte en verificatie van referenties.
Het updatepad hangt af van de DID-methode. Met deed:web, werk je het gehoste DID-document bij. Met deed:ethr, publiceer je een transactie in het register. Het moeilijke gedeelte is continuïteit: verificateurs moeten weten welke sleutel geldig was toen een credential werd uitgegeven en of die credential sindsdien is ingetrokken, verlopen of vervangen.
En dat brengt ons bij DID methoden, omdat de methode precies definieert hoe creatie, resolutie, updates en deactivatie werken in het echte systeem.
Een DID-methode is de implementatielaag achter de standaard DID-syntaxis.
Het definieert de regels voor:
Met andere woorden, de DID-syntaxis is standaard (did:methode:identificator), maar de methode geeft vorm aan het hele infrastructuurmodel achter de DID.
Deze drie methoden dekken de meeste echte gebruikssituaties:
De tabel geeft je de mechanica. Het moeilijkste is om te beslissen met welke foutmodus je kunt leven: DNS afhankelijkheid, ketenkosten, geen rotatie, openbare controleerbaarheid of zwakkere overdraagbaarheid. Dus hier is mijn kijk op hoe te kiezen.
Stel voordat je kiest de lelijke productievragen:
In echte implementaties worden methoden meestal gemengd. Uitgevers gebruiken vaak deed:web of deed:ethr; houders gebruiken paarsgewijze of kortstondige identifiers. Deze splitsing houdt het vertrouwen van de uitgever stabiel terwijl het correlatierisico voor gebruikers wordt verminderd.
Laten we er geen doekjes om winden: je hebt geen blockchain nodig om gedecentraliseerde identiteit te implementeren. De DID Core-specificatie van het World Wide Web Consortium vereist dit niet en veel productiesystemen draaien volledig off-chain.
Dus waarom is blockchain eigenlijk een gespreksonderwerp? Omdat het één specifiek probleem heel goed oplost: gedeeld vertrouwen zonder centrale eigenaar. Geen opslag, geen identiteit zelf, maar coördinatie rond sleutels, identifiers en status.
In DID-gebaseerde systemen fungeert blockchain als een openbaar, fraudebestendig register. Afhankelijk van de methode kan het worden gebruikt om:
Het belangrijkste punt: de blockchain verifieert de identiteit niet. Het biedt een gemeenschappelijk referentiepunt waar verificateurs op kunnen vertrouwen zonder een enkele partij te vertrouwen.
Bijvoorbeeld met deed:ethr, De DID zoekt naar gegevens op de keten. De verificateur vertrouwt op de toestand van de keten, niet op de infrastructuur van de uitgever.
Dit is waar veel DID-implementaties de mist in gaan. Blockchain is nuttig voor een gedeelde staat, maar het is een vreselijke plek voor ruwe identiteitsgegevens. Je zet geen paspoorten, biometrische gegevens, volledige referenties of persoonlijke gegevens op de ketting. Je gebruikt de keten voor bewijsmateriaal en coördinatiegegevens en houdt vervolgens gevoelige identiteitsgegevens buiten de keten.
Een zuivere splitsing ziet er meestal zo uit:
On-chain:
Off-chain:
De reden is simpel: privacy en kosten. Blockchains zijn openbaar, permanent en kostbaar om bij te werken. Identiteitsgegevens hebben privacy, verwijdering, correctie en toegangscontrole nodig. Die twee gaan niet samen.
Blockchain wordt meestal gebruikt voor verankering, niet voor opslag. Je legt een klein bewijs van de toestand vast aan de keten, zoals een hash van een DID-document, een update van het emittentenregister, een referentie naar de status van het certificaat of een sleutelrotatiegebeurtenis, terwijl de eigenlijke identiteitsgegevens buiten de keten blijven.
Dat geeft verificateurs drie nuttige eigenschappen:
De afweging is permanentie. Als je de verkeerde gegevens op de ketting zet, kun je ze niet netjes verwijderen. Daarom verankeren volwassen DID-systemen hashes, referenties en statustransities, geen volledige referenties, documenten of persoonlijke gegevens.
Blockchain is het verkeerde gereedschap wanneer het een vertrouwensafhankelijkheid niet verwijdert. Als dezelfde organisatie de emittent, verificateur en applicatie controleert, voegt het on-chain plaatsen van de DID-status meestal alleen maar kosten, latentie en operationele ruis toe.
Sla blockchain over wanneer:
Daarom deed:web zo goed werkt voor veel identiteitsstromen binnen bedrijven. Het behoudt het DID-model, maar maakt gebruik van bestaande webinfrastructuur in plaats van elke update te forceren via een blockchaintransactie.
Gebruik blockchain als onafhankelijke partijen een gedeelde staat nodig hebben die ze kunnen verifiëren zonder uw server te vertrouwen. Houd het anders off-chain. Meer decentralisatie op papier betekent niet automatisch een betere identiteitsarchitectuur.
In systemen zoals de digitale identiteitsportefeuille van de EU of mobiele rijbewijzen (ISO 18013-5) is grotendeels voor PKI gekozen omdat openbare L1/L2-netwerken niet voldoen aan de kernvereisten voor identiteit: privacy, gegevenssoevereiniteit en wettelijke controle. Identiteitsgegevens kunnen niet publiekelijk worden gekopieerd en rechtsgebieden hebben strikte controle nodig over waar gegevens worden verwerkt en opgeslagen.
Maar nieuwere architecturen introduceren een derde optie: toegelaten zk-L2 systemen. Deze combineren:
Het kernidee is de scheiding van belangen op infrastructuurniveau:
Dit vermijdt een belangrijke beperking van openbare ketens: de blootstelling van gegevens. Tegelijkertijd wordt een beperking van pure PKI vermeden: vertrouwen op gesloten vertrouwenshiërarchieën zonder gedeelde controleerbaarheid.
Een andere belangrijke eigenschap is multi-domein architectuur. Verschillende actoren - ministeries, toezichthouders, banken of regio's - kunnen opereren in afzonderlijke uitvoeringszones met hun eigen nalevingsgrenzen, terwijl ze toch bijdragen aan een gedeelde verifieerbare staat door middel van bewijzen.
Dit vergroot de ontwerpruimte voor identiteitssystemen. In plaats van te moeten kiezen tussen gecentraliseerde PKI en publieke blockchain, kunnen nieuwe implementaties privacy, compliance en gedeeld vertrouwen combineren in één enkel model.
Ok, nu zou het duidelijk moeten zijn wat DID's anders doen dan standaard KYC. Maar de meer praktische vraag is: Wat verandert dat eigenlijk voor mij? Eerlijke vraag. Van wat ik heb gezien in echte implementaties, hangt de impact sterk af van aan welke kant je staat, dus het is de moeite waard om het uit te splitsen.
Voor gebruikers is de grootste verschuiving de controle over wanneer en hoe identiteit wordt gedeeld.
In de praktijk verandert identiteit hierdoor van iets dat je steeds opnieuw indient in iets dat je aanwezig wanneer nodig.
Voor organisaties gaat de verschuiving minder over UX en meer over risico- en kostenstructuur.
Wat er operationeel verandert, is het volgende: je stopt met het bewaren van gegevens en begint met het zijn van een verificateur van claims.
Voor ontwikkelaars is de waarde in hoe identiteitslogica is opgebouwd.
Vanuit een technisch standpunt is de verschuiving van “gebruikers en sessies beheren” naar bewijzen verifiëren en voorwaarden afdwingen.
Laten we de theorie even achterwege laten en dit gewoon doorlopen zoals we dat in een echt systeem zouden doen. Wat doet DID eigenlijk zin hebben in in de praktijk? Waar houdt het op een diagram te zijn en begint het iets te worden dat je zou verschepen?
Je zult onderweg iets merken: de objecten veranderen - diploma, werkgeschiedenis, KYC-status - maar de stroom verandert nauwelijks.
Stel, je bent net afgestudeerd en je moet je diploma bewijzen aan een toekomstige werkgever. De gebruikelijke weg is onhandig: een PDF uploaden, een scan bijvoegen, misschien wachten tot iemand de registrar mailt. Het werkt, maar nauwelijks. Het hele proces is afhankelijk van handmatig vertrouwen.
Met een DID-certificaat geeft de universiteit een verifieerbaar certificaat af wanneer je afstudeert. Het zit in je portemonnee, ondertekend door een sleutel die is gepubliceerd in het DID-document van de universiteit.
Maanden later solliciteer je naar een baan. De werkgever hoeft geen contact op te nemen met de universiteit. Je legt je referenties voor en hun systeem controleert ze:
Dat is het mooie van het model: de universiteit ondertekent eenmaal, u hergebruikt het bewijs en elke verificateur kan het onafhankelijk controleren.
Hoeveel van een CV vertrouw je eigenlijk? Titels worden opgeblazen. Data worden vaag. “Een team leiden” kan van alles betekenen, van het managen van tien mensen tot het leiden van stand-ups.
Draai nu het model om. Als je een bedrijf verlaat, geven ze je een referentie:
De volgende keer dat iemand vraagt: “Kun je bewijzen dat je X hebt gedaan?” leg je het niet uit. Je presenteert. En nee, dat betekent niet dat je elke keer je hele werkverleden moet laten zien. Met het juiste formaat kan de houder een beperktere claim bewijzen, zoals:
...zonder het volledige arbeidsverleden te overhandigen. Dat is een heel andere houding dan “stuur ons je volledige CV en referenties”.”
Hier wordt herbruikbare identiteit duidelijk. Je verifieert eenmalig bij een betrouwbare provider: paspoort gecontroleerd, sancties doorgelicht, jurisdictie bevestigd. De provider geeft een KYC-creditential af aan je portemonnee.
Volgende platform? Je presenteert de referenties in plaats van dezelfde documenten opnieuw te uploaden. Het platform controleert:
Sommige tokenisatieteams gebruiken ook zielsgebonden penningen als on-chain KYC-markers: dit adres heeft de vereiste controle doorstaan. De identiteitsgegevens blijven off-chain; de keten draagt alleen het geschiktheidssignaal.
Nuttig, maar alleen als de markering breed en herroepbaar is en geen permanent privacylek is.
Gezondheidszorg is waar DID-architectuur een korte leiband nodig heeft. Stel dat een kliniek je een vaccinatiecreditential geeft, een lab tekent je bloedtestuitslag en je arts geeft een receptcreditential uit. Die bewaar je in je portemonnee in plaats van dat je elk document in een ander portaal laat verdwijnen.
Dan verander je van dokter. Wacht je tot het ene systeem met het andere praat? Achter PDF's aanzitten? Nee. Je deelt de specifieke referenties die de nieuwe arts nodig heeft. Zij verifiëren de uitgever, de handtekening en de status.
En voor alle duidelijkheid: dit alles vereist niet dat medische gegevens on-chain worden gezet. De keten is voor identifiers, sleutels, misschien statusregisters. De gevoelige gegevens blijven buiten de keten. Als die grens niet gerespecteerd wordt, is het ontwerp kapot.
Laten we even afstand nemen van mensen. Pak een product, bijvoorbeeld een fles olijfolie. Premium label, mooie verpakking. Is het echt? In plaats van het merk te vertrouwen, tik je met je telefoon op een NFC-tag. Achter die tag zit een DID die gekoppeld is aan de partij van het product.
Wat je terugkrijgt zijn ondertekende gegevens:
Je kunt het product letterlijk volgen van bron tot schap. Lost het alles op? Nee. Als de eerste gegevensinvoer fout is, blijft de fout bij alles wat daarna komt. Maar je weet nu tenminste die elke stap ondertekend. Dat is een grote verbetering ten opzichte van “vertrouw ons”.”
Overheid is waar DID-identiteit de cryptobubbel verlaat. Een belangrijk referentiepunt is de EU Digital Identity Wallet in het kader van eIDAS 2.0, een grootschalig initiatief dat tot doel heeft portefeuilles te verstrekken aan burgers, inwoners en bedrijven in alle lidstaten.
Maar het bredere landschap is diverser. Sommige van de grootste en meest volwassen digitale identiteitssystemen wereldwijd zijn niet strikt DID-gebaseerd, maar volgen toch vergelijkbare patronen rond herbruikbare referenties en door de houder gecontroleerde gegevens:
De gemeenschappelijke verschuiving in deze systemen is hetzelfde: van gecentraliseerde identiteitsbestanden naar herbruikbare, door de gebruiker gepresenteerde bewijzen. Tegelijkertijd is het belangrijk om de vertrouwensmodellen te scheiden. Systemen zoals eIDAS vertrouwen op gefedereerde PKI en vertrouwenslijsten, terwijl DID-gebaseerde systemen vertrouwen op cryptografische identifiers en verifieerbare geloofsbrieven. In de praktijk bestaan deze modellen vaak naast elkaar in plaats van elkaar te vervangen.
Tot nu toe werkt alles prima binnen één systeem. Maar wat gebeurt er als referenties systeemgrenzen overschrijden? Dan worden de dingen moeilijk. Je hebt gedeelde standaarden nodig zodat de gegevens overal kloppen, en je hebt governance nodig zodat verificateurs weten welke uitgevers ze kunnen vertrouwen. Dit zijn de standaarden en governancelagen die het belangrijkst zijn.
Standaarden maken referenties interoperabel. Governance maakt ze acceptabel. Zonder standaarden wordt niets geparseerd. Zonder governance wordt niets vertrouwd. Echte systemen werken alleen als beide lagen samen gedefinieerd zijn.
Standaarden vertellen je hoe een DID-systeem zich zou moeten gedragen. Productie vertelt je waar het rommelig wordt. Vandaag de dag komen de meeste risico's niet van de DID syntaxis of handtekening algoritmes zelf. Ze ontstaan rond wallets, sleutelherstel, intrekking, interoperabiliteit en of genoeg uitgevers en verificateurs het eens zijn om hetzelfde vertrouwensmodel te gebruiken.
In DID-systemen hangt identiteit af van sleutelcontrole. Dat is krachtig, maar meedogenloos. Als een gebruiker de sleutel verliest, is herstel niet automatisch. Als een aanvaller de sleutel bemachtigt, kan hij zich voordoen als de houder. Daarom vertrouwen serieuze implementaties zelden alleen op een ruwe zaadzin. Ze hebben meestal MPC, sociaal herstel, hardware-ondersteunde sleutels of een hybride bewaarmodel nodig.
Geloofsbrieven verouderen. KYC vervalt, werknemers vertrekken, licenties worden geschorst. Verificatie kan dus niet stoppen bij “is de handtekening geldig?”. De verificateur controleert de status van het document op het moment van gebruik. Dat betekent meestal statuslijsten, intrekkingsregisters of credentials met een korte levensduur. Als je dit deel mist, blijven oude referenties er geldig uitzien.
Standaarden helpen, maar ze zorgen er niet voor dat elke portemonnee, uitgever en verificateur compatibel is. De ene stack kan JSON-LD referenties gebruiken, een andere kan de voorkeur geven aan JWT. DID-methoden. Presentatieprotocollen verschillen. Dus ja, het ecosysteem beweegt zich in de richting van interoperabiliteit, maar echte projecten hebben nog steeds integratiewerk en strikte profielkeuzes nodig.
Het moeilijkste deel is coördinatie. Een DID-systeem heeft emittenten nodig die mensen vertrouwen, verificateurs die bereid zijn om referenties te accepteren, gebruikers die portefeuilles kunnen beheren en governanceregels die iedereen begrijpt. Totdat deze onderdelen op één lijn liggen, gebeurt de adoptie eerst in kleine stapjes: gereguleerde financiering, tokenisatie, personeelsreferenties, ID van de overheid en gesloten ecosystemen.
De meeste DID-systemen maken tegenwoordig gebruik van cryptografie met elliptische curve: Ed25519, secp256k1 of P-256. Deze schema's worden op grote schaal gebruikt, maar ze zijn niet post-quantum veilig. Een voldoende krachtige kwantumcomputer zou ze kunnen breken met het algoritme van Shor, waardoor vervalsing van handtekeningen een reëel langetermijnrisico wordt.
Dat is belangrijk omdat identiteitsgegevens vaak jaren meegaan. Diploma's, rijbewijzen en wettelijke attesten die vandaag worden uitgegeven, moeten mogelijk nog worden geverifieerd lang nadat de cryptografie erachter is uitgeput.
Standaarden gaan al die kant op. NIST heeft post-kwantum handtekeningschema's afgerond zoals ML-DSA (Dilithium) en SLH-DSA (SPHINCS+), terwijl het DID/VC ecosysteem hybride handtekeningen en crypto-agility onderzoekt.
DID-systemen moeten vanaf dag één meerdere verificatiemethoden, nieuwe handtekeningssuites en duidelijke sleutelrotatiepaden ondersteunen. Post-kwantum handtekeningen zijn veel groter dan Ed25519 of ECDSA handtekeningen, wat invloed heeft op QR presentaties, registers en on-chain statusmechanismen. Maar voor langlevende overheids- en bedrijfsidentiteit is crypto-agility een must.
De fout die we het vaakst zien is dat we DID behandelen als iets dat je “toevoegt” aan een bestaande identiteitsstapel. In de praktijk is het een verschuiving in hoe je vertrouwen, gegevensstromen en verantwoordelijkheid modelleert. De technische stukken zijn zelden het moeilijkste deel. De meeste projecten slagen of falen op basis van coördinatie, governance en integratie.
Begin met het identificeren waar u identiteitsgegevens opslaat om ze later te verifiëren: KYC-status, leeftijd, werk, licenties, accreditatie en toegangsrechten. Het doel is om minder ruwe gegevens op te slaan en meer ondertekende claims te verifiëren. Dat vermindert aansprakelijkheid, vereenvoudigt compliance en maakt identiteit overdraagbaar tussen systemen.
Definieer het vertrouwensmodel in concrete termen voordat je tools kiest. In echte projecten resulteert dat meestal in:
Zonder dit krijg je referenties die correct verifiëren, maar niet geaccepteerd worden door verificateurs.
Kies nu de technische stapel. Kies de DID-methode, het credential formaat, de wallet flow en het revocation model. deed:web past meestal bij bedrijfs- en SaaS-stromen. deed:ethr past smart contract handhaving en on-chain identiteit. did:key past op kortstondige of lokale identifiers.
Kies niet de meest “gedecentraliseerde” optie. Kies degene die overeenkomt met je vertrouwensgrens.
Begin niet met “identiteit voor alles”. Begin met één stroom waarbij de pijn duidelijk is. Goede pilots zijn onder andere:
Beperk de scope: één type credential, één of twee uitgevers, één verificatiestroom, duidelijke intrekkingsregels. Vermijd te beginnen met:
Bewijs de stroom van begin tot eind en breid dan uit.
Zodra je van een pilot naar productie gaat, is het uitgeven van credentials nog maar de helft van het probleem. De moeilijkere vraag is wat er gebeurt als een credential niet meer vertrouwd kan worden: een KYC-controle verloopt, een medewerker vertrekt, een licentie wordt geschorst of een portemonnee is gecompromitteerd.
Er is niet één standaardaanpak en elk model heeft nadelen:
Verschillende ecosystemen hanteren verschillende benaderingen. Bijvoorbeeld, ISO 18013-5 mobiele rijbewijzen vertrouwen op validatie van de uitgever en vertrouwenslijsten in plaats van W3C-achtige intrekking. Zonder een duidelijke intrekkingsstrategie breekt het “herbruikbare referenties”-model. Een gecompromitteerd legitimatiebewijs kan gepresenteerd blijven worden tenzij de status actief wordt gecontroleerd.
Een typisch DID/VC-project verloopt in fasen. Een pilot duurt meestal 3-4 maanden en valideert één use case end-to-end, meestal in het bereik van $150K–$300K, afhankelijk van de omvang. Een productie-uitrol duurt 9-12 maanden en breidt uit naar meerdere verstrekkers, verificateurs en typen referenties, meestal variërend van $800K tot $2M+, afhankelijk van de complexiteit van de integratie en de nalevingsvereisten.
Een typisch team bestaat uit:
In de praktijk zit de complexiteit zelden in de cryptografie. Het zit in integratie, beheer en gebruikerservaring.
Laten we een beetje uitzoomen om dit af te ronden. DID-gebaseerde identiteit is geen kant en klare oplossing. Het is nog steeds in ontwikkeling, vooral rond bewijssystemen, portemonnee-infrastructuur, interoperabiliteitslagen en wettelijke integratie. Van wat ik zie in echte implementaties, worden een paar richtingen duidelijk.
Herbruikbare identiteit is het voor de hand liggende eindspel, maar het knelpunt is niet de verificatie van handtekeningen. Dat deel werkt al. Moeilijker is het vertrouwen van de uitgever, credential schema's en acceptatieregels.
In de toekomst zou een KYC-creditential die is uitgegeven in één gereguleerde omgeving herbruikbaar moeten zijn op beurzen, tokenization-platforms, leenproducten en DeFi interfaces die aan de regels voldoen, op voorwaarde dat de DID van de uitgever kan worden opgelost, het schema wordt begrepen en de verificateur de uitgever accepteert binnen zijn vertrouwensraamwerk. Dat is waar het echte werk zit: niet bewijzen dat een handtekening geldig is, maar het eens worden over wat de ondertekende claim eigenlijk betekent.
Vandaag de dag onthullen veel systemen nog kenmerken. De toekomst is het aantonen van voorwaarden. In plaats van je geboortedatum te tonen, bewijs je dat je ouder dan 18 bent. In plaats van volledige KYC-gegevens weer te geven, bewijs je dat je voldoet aan een bepaald nalevingsbeleid. In plaats van een jurisdictieveld te delen, bewijs je dat je in aanmerking komt voor een transactie.
Technisch gezien wijst dit in de richting van BBS+ handtekeningen voor selectieve openbaarmaking en zk-SNARKs of zk-STARKs voor predicaatbewijzen. De verificateur controleert het bewijs aan de hand van door de uitgever gecontroleerde openbare sleutels, terwijl de onderliggende persoonlijke gegevens verborgen blijven. Dat verandert het privacymodel van “deel minder gegevens” naar “deel de gegevens helemaal niet als een bewijs genoeg is”.”
Interoperabiliteit zal bepalen of gedecentraliseerde identiteit gefragmenteerd blijft of een bruikbare infrastructuur wordt.
De zwakke punten zijn nog steeds bekend: JSON-LD vs JWT referenties, verschillende DID methodes, verschillende wallet protocollen, verschillende presentatiestromen. Daarom definiëren productiesystemen steeds vaker strikte profielen: goedgekeurde formaten voor referenties, ondersteunde DID-methoden, vertrouwde uitgevers en geaccepteerde presentatieprotocollen.
Na verloop van tijd verwacht ik meer convergentie rond wallet-to-verifier flows, presentatie-uitwisseling en vertrouwensregisters. Zonder dat wordt elk DID-project een identiteitseiland. Als dat er wel is, kunnen referenties van het ene platform naar het andere verhuizen zonder dat er telkens een aangepaste integratie nodig is.
Regelgeving verandert gedecentraliseerde identiteit van een technische optie in een openbare infrastructuur.
In de EU zijn eIDAS 2.0 en de EU digitale identiteitspoort het grote signaal. Lidstaten zijn verplicht om de portemonnee-infrastructuur aan te bieden, met referenties voor identiteitsattributen, licenties, kwalificaties en publiek-private sector use cases. Dat creëert een gereguleerde credentielaag in heel Europa.
In de VS is het National Institute of Standards and Technology bezig met het bijwerken van de richtlijnen voor digitale identiteit (bijv. NIST 800-63) om rekening te houden met cryptografische referenties, garantieniveaus en verificatie met behoud van privacy. De VS zal waarschijnlijk vasthouden aan een meer marktgedreven model, terwijl de EU een gecoördineerd portemonneekader voorstaat.
Waar gaat dit naartoe? Naar minder documenten uploaden, meer herbruikbare referenties, meer lokale cryptografische controles en meer selectieve openbaarmaking. De winnaars zullen niet de systemen zijn die de meeste identiteitsgegevens opslaan. Zij zullen degenen zijn die de juiste claim kunnen verifiëren met de minste blootstelling.
Een gedecentraliseerde identifier is een unieke, herleidbare identifier die verwijst naar een DID-document dat openbare sleutels en verificatiemethoden bevat. Hiermee kunnen entiteiten hun identiteit of controle bewijzen zonder afhankelijk te zijn van een centrale autoriteit. In de praktijk vervangt het het opzoeken in een database door cryptografische verificatie.
Een DID verwijst naar een DID-document met publieke sleutels. Een uitgever ondertekent een credential, een houder slaat het op en een verificateur controleert de handtekening en status met behulp van de DID van de uitgever. Er is geen directe oproep naar de uitgever nodig. Dit maakt verificatie overdraagbaar en onafhankelijk van een enkel systeem.
Decentrale identiteit is het overkoepelende model voor het uitgeven en verifiëren van claims zonder centrale opslag. Een DID is slechts één onderdeel van dat model. Het fungeert als de identificatielaag die gebruikt wordt om sleutels op te lossen en handtekeningen te verifiëren. Zonder DID's zou het systeem een consistente manier missen om verificatiemateriaal te vinden en te vertrouwen.
Niet noodzakelijkerwijs. Sommige DID-methoden gebruiken blockchains voor resolutie of verankering, maar vele, zoals deed:web, vertrouwen op standaard webinfrastructuur. De DID zelf is een referentie, geen gegevensrecord. Wat op de ketting kan worden opgeslagen zijn sleutels, hashes of statusreferenties, geen identiteitsgegevens.
Ze worden gebruikt om identiteiten te koppelen aan cryptografische sleutels, verifieerbare referenties mogelijk te maken, herbruikbare KYC te ondersteunen, personeelsverificatie, digitale ID's en toegangscontrole in zowel web- als blockchaingebaseerde systemen. Hun rol is om identiteitsverificatie overdraagbaar te maken tussen systemen.
Je genereert een sleutelpaar en maakt een DID aan volgens een gekozen methode. Vervolgens publiceer of registreer je het zodat het kan worden omgezet in een DID-document. Het exacte proces hangt af van de DID-methode (bijv. web, blockchain of sleutelgebaseerd). De methode bepaalt hoe de DID wordt verankerd, bijgewerkt en opgelost.
Blockchain expert & DeFi analist
Andrew vertaalt gedecentraliseerde concepten in veilige, functionele financiële tools. Hij navigeert door het vluchtige DeFi-landschap om schaalbare blockchain-infrastructuren te bouwen die het echte nut aanspreken, en gaat voorbij aan de modewoorden om technische waarde te leveren.
