Uit een door de Autoriteit Persoonsgegevens (AP) in 2019 gepubliceerd onderzoek over privacy bleek dat maar liefst 94% van de ondervraagde zich zorgen maakt over de bescherming van zijn of haar persoonsgegevens. Één op drie mensen maakt zich zelfs veel of heel veel zorgen. Mensen maken zich vooral zorgen over misbruik van (een kopie van) hun identiteitsbewijs, organisaties die hun online zoekgedrag volgen en hen volgen via het wifi-signaal van hun mobiele telefoon. Bescherming van de privacy is daarmee een breed gedeelde zorg.

Ondanks de toegenomen privacy wetgeving zoals de Wet bescherming persoonsgegevens (wbp) of de in 2018 ingevoerde Algemene Verordening Gegevensbescherming (AVG) maken mensen zich nog steeds ernstig zorgen over wat er precies gebeurt met hun data. Een nieuwe stap in de wereld van privacy en informatiebeveiliging moet deze zorgen bij mensen gaan verminderen. Deze stap is in de richting van Self-Sovereign Identity.

Wat is Self-Sovereign Identity?

Self-Sovereign Identity (SSI) is een term die wordt gebruikt om een digitaal idealisme te beschrijven die erkent dat een individu over zijn of haar digitale identiteit moet bezitten zonder tussenliggende administratieve autoriteiten. SSI moet mensen in staat stellen om in de digitale wereld te communiceren met dezelfde vrijheid en vertrouwen als in de “offline” wereld. Zo heeft iedereen in de offline wereld verschillende unieke attributen van identificerende informatie. Dit zijn attributen zoals een paspoort, diploma’s, een rijbewijs of (bedrijfs)licenties. In de fysieke wereld worden deze attributen weergegeven in de vorm van pasjes, kaarten en/of certificaten die door de identiteitshouder in een portemonnee of veilige kluis worden bewaard. Vervolgens kunnen deze attributen gepresenteerd worden wanneer de persoon zijn identiteit of een onderdeel over zijn identiteit moet bewijzen.

SSI-technologie maakt het voor eenieder mogelijk om de regie van digitale (persoonlijke) gegevens volledig in eigen handen te krijgen. Als consument verzamel je data over jezelf en laat je die één keer digitaal ondertekenen door bijvoorbeeld overheden, banken, werkgevers, verzekeraars of onderwijsinstellingen. Die gegevens kan je voortaan gebruiken voor het aangaan van allerlei (elektronische) transacties. Vervolgens is er dus geen reden meer voor het controleren van papieren bij het verstrekken van een verzekering of het huren van een auto. Door gebruik te maken van SSI kunnen complexe administratieve processen zo ontworpen worden dat je in één klik, al je zaken online en real-time kunt regelen, volledig privacy vriendelijk. De gegevens beheer je in een ‘wallet’-app op je telefoon in de vorm van “credentials”. En jij bepaalt welke informatie je met welke partijen deelt.

Daarnaast biedt SSI de mogelijkheid voor zero-knowledge proof (ZKP) protocollen. Met ZKP kan je iets (bijvoorbeeld een leeftijd) verifiëren zonder het daadwerkelijk te onthullen. Op deze manier wordt de privacy van een individu nog beter ondersteund, want exacte gegevens worden niet gedeeld. De term “zero knowledge” komt voort uit het feit dat er geen (“zero”) informatie over het geheim onthult wordt tijdens een communicatieve transactie tussen twee of meerdere partijen.

Onder het kopje Praktijkvoorbeelden (voorbeeld 3)" wordt een voorbeeld gegeven van ZKP.

Het Proces

Het proces binnen SSI kent 3 belangrijke begrippen: Issuers (Verstrekkers), Holders (Houders) en Verifiers (Verificateurs).

Issuer

Issuers zijn instanties zoals bedrijven, overheden en gemeenten die verifieerbare digitale credentials kunnen verstrekken aan holders. Voorbeelden van digitale credentials zijn identiteitsbewijzen (paspoort, id-kaart, bedrijfs- of service-ID-kaart…), rijbewijzen (auto / motorfiets, vliegtuigen…), certificaten (middelbare schooldiploma, bachelordiploma, masterdiploma…), bevestigingen (authenticiteitsbevestiging, vaccinatiebevestiging,…) kwalificaties (BIG registraties voor verpleegkundige,…. ), bevoegdheden (officiële autoriteit, verblijfsautoriteit…),. Issuers zijn bijvoorbeeld gemeentes, wegenverkeersbureaus, scholen en universiteiten, bedrijven, beroepsverenigingen of kwalificatieorganisaties. De credentials worden digitaal ondertekend door de issuers en geplaats op de blockchain waardoor autheniciteit wordt gewaarborgd.

Holder

Een Holder is een individu of organisatie wat wat beschikt over digitale credentials. Deze digitale credentials kunnen veilig bewaard worden in zogeheten “wallets”, ofwel digitale portemonnees. Holders kunnen digitale credentials ontvangen of aanvragen bij issuers om ze later te bewijzen aan verifiers voor goederen of diensten. De holder kan dan zelf bepalen welke gegevens gedeeld worden met de verfier en voor hoelang.

Verifier

Verifiers zijn instanties die digitale credentials kunnen opvragen van holders om processen of aanvragen te verwerken. Idealiter gebeurt dit volledig automatisch. De verifier kan de digitale handtekening (uit de blockchain) van de issuer gebruiken, om de authenticiteit van de digitale credentials te verifiëren. Het is van essentieel belang dat de overdracht van de digitale credentials tussen holder en verifier versleuteld verloopt, anders is het een groot doelwit voor cybercriminelen.

Verfiers kunnen net zoals issuers: gemeentes, wegenverkeersbureaus, scholen en universiteiten, bedrijven, beroepsverenigingen of kwalificatieorganisaties zijn, maar dan in de vorm van een controlerende partij i.p.v een verstrekkende.

Het plaatje hieronder geeft een schematische weergave van het proces tussen issuers, holders en verifiers. (De “Trust” tussen issuer en verifier wordt opgezet d.m.v de onderliggende blockchain)

issuer-holder-verifier

Praktijkvoorbeelden

Stel jezelf de volgende vraag: welke informatie heeft de andere partij (de verifier) van mij nodig om iets te verifiëren? Alleen mijn naam? Alleen mijn naam en leeftijd? Misschien alleen mijn lengte…. of moet er simpelweg geverifieerd worden of ik 18+ ben? Dan is er nog de vraag waarom deze gegevens gevraagd worden, welk doeleinde, waar worden deze gegevens precies opgeslagen en voor hoelang? Wat gebeurt er met mijn gegevens zodra ik eis dat ze verwijderd worden of wanneer de andere partij ze niet meer nodig heeft? Dit zijn allemaal vragenstukken waar SSI een oplossing voor moet bieden. Een aantal voorbeelden:

Voorbeeld 1

Situatie zonder SSI

Bob slaapt een weekend in een hotel. Bij de check-in vraagt de baliemedewerker of Bob een identiteitsbewijs kan overhandigen waarmee zijn naam en woonplaats geverifieerd kan worden.

In dit geval verschilt het per land welke gegevens noodzakelijk zijn. In Nederland is dat je naam, woonplaats en het type identiteitsbewijs, dus een paspoort, identiteitskaart of een rijbewijs.

Bob overhandigd zijn fysieke paspoort waaruit de baliemedewerker de nodige informatie haalt voor het in-check process. Vervolgens maakt de baliemedewerker een kopie van zijn gehele paspoort (dus ook van Bob’s BSN, geboortedatum, foto en paspoortnummer) en slaat deze ergens op.

Bob weet nu niet waar deze kopie bewaard wordt en wat er mee gebeurt zodra hij weer uitcheckt. Bob is hierdoor de controle kwijt over zijn gevoelige gegevens en liggen hiermee dus in handen van een derde partij. Te hopen voor Bob dat deze gegevens niet op straat terecht komen wat kan leiden tot identiteitsfraude of andere narigheden.

Situatie met SSI

Bob slaapt een weekend in een hotel. Bij de check-in vraagt de baliemedewerker of Bob een identiteitsbewijs kan overhandigen waarmee zijn naam en woonplaats geverifieerd kan worden.

In plaats van dat Bob zijn fysieke paspoort overhandigd, vraagt de baliemedewerker aan Bob om een QR-code te scannen om een actieve connectie op te zetten tussen bob en het hotel. Bob scant de QR-code. Nadat de connectie is opgezet stuurt de baliemedewerker een digitale verzoek om specifieke identititeits attributen vanuit Bob’s paspoort te ontvangen, inclusief de reden waarom deze attributen nodig zijn. In dit geval stuurt de baliemedewerker een verzoek voor Bob’s naam en woonplaats. Bob krijg de aanvraag binnen op zijn digitale wallet, controleert de reden waarom de gegevens nodig zijn en drukt op “accepteren”. De baliemedewerker heeft nu de gegevens die hij nodig om Bob in te kunnen checken. Bob weet nu precies welke gegevens het hotel van hem heeft ontvangen en waarom.

Als Bob uitcheckt trekt hij het verzoek weer in en kan niemand van het hotel meer bij zijn gegevens. Bob hoeft zich nu geen zorgen meer te maken of zijn gegevens op straat terecht komen, want de gegevens staan alleen nog op zijn wallet.

  • Bob is in dit geval de holder en heeft in zijn wallet een paspoort als digitale credential.
  • De gemeente heeft de digitale credential (het paspoort) verstrekt aan Bob en de digitale handtekening geplaatst op de blockchain. De gemeente is dus de issuer
  • Het hotel wil controleren of de opgevraagde credential van Bob legitiem is en controleert hiervoor de authenticiteit op de blockchain. Het hotel is dus de verifier

Voorbeeld 2

Situatie zonder SSI

Bob wil een nieuw twitteraccount aanmaken. Bij het registreren moet hij voor de zoveelste keer een gebruikersnaam en wachtwoord invoeren. Aangezien Bob een troller is, maakt hij een nep account aan met een wachtwoord wat hij vaak gebruikt. Hij registreert zichzelf onder het pseudoniem “Anomiem123”.

Bob aka “Anomiem123” deelt graag zijn mening online. Ook op twitter gaat hij er aardig op los. Hij plaatst zo’n 25 berichten per dag waarin hij zijn mening ongefilterd verkondigd.

Het gedrag van Bob slaat al snel om. Bob is het niet eens met de mening van een ander en stuurt daarom regelmatig doodsbedreigingen. Het loopt zelfs zo uit de hand dat de gene die de dreigementen van Bob ontvangt, beschermt moeten worden door de politie.

Er wordt aangifte gedaan van bedreiging. De politie onderzoekt waar de dreigementen vandaan komen maar stuiten op het pseudoniem Anomiem123. Het kost de politie enorm veel tijd om te achterhalen wie er achter het pseudoniem zit en aangezien de politie het erg druk heeft met andere online dreigementen beland de aangifte op de stapel.

Bob maakt het niets uit, hij is toch anoniem en gaat dus gewoon door.

Situatie met SSI

Bob wil een nieuw twitteraccount aanmaken. Bob ziet dat hij moet registreren met zijn SSI identiteit van zijn paspoort, rijbewijs of id-kaart credential. Bob klikt op “registeren met SSI” en krijgt een QR-code te zien om een actieve connectie op te zetten met twitter. Bob scant te QR-code en krijgt automatisch een verzoek toegestuurd met daarin onder andere, de vraag naar zijn volledige naam. Ondanks dat Bob een troller is moet hij nu accepteren dat de registratie plaatsvindt onder zijn eigen naam. Het lukt hem dus niet om te registreren onder een pseudoniem, want zijn credential wordt geverifieerd op de blockchain.

Bob registreert zichzelf met zijn rijbewijs credential onder de naam Bob de Jong. Hij hoeft hiervoor geen wachtwoord meer te gebruiken, volgende keer kan hij namelijk inloggen met zijn identiteit.

Bob aka “Bob de Jong” deelt nog steeds zijn mening online. Hij plaats zo’n 25 berichten per dag waarin hij zijn mening ongefilterd verkondigd. Hij doet dit wel onder zijn eigen naam, dus ook als hij doodsbedreigingen wil versturen.

Het aantal nep accounts en dreigementen is bij alle social media platformen dankzij SSI implementaties drastisch verminderd. Datalekken zijn een fenomeen van het verleden, want niemand maakt meer gebruik van (zwakke) wachtwoorden die beheert worden door een derde partij.

  • Bob is in dit geval de holder en heeft in zijn wallet een rijbewijs als digitale credential.
  • De gemeente heeft de digitale credential (het rijbewijs) verstrekt aan Bob en de digitale handtekening geplaatst op de blockchain. De gemeente is dus de issuer
  • Het social media platform (twitter) wil controleren of de opgevraagde credential (het rijbewijs) van Bob legitiem is en controleert hiervoor de authenticiteit op de blockchain. Het social media platform is dus de verifier

Voorbeeld 3

Situatie zonder SSI

Bob is 17 jaar en wil een avondje stappen. De uitsmijter wil bij de ingang controlleren of hij 18 jaar of ouder is om naar binnen te mogen. Bob overhandigd zijn id-kaart. De uitsmijter ziet nu de naam van Bob, zijn geboortedatum, zijn geboorteplaats, zijn bsn, zijn foto en het documentnummer van zijn kaart. De uitsmijter maakt nog even een grap over de oude foto van Bob om vervolgens te concluderen dat Bob 22 jaar oud is, want hij heeft zijn leeftijd vervalst. De uitsmijter laat Bob naar binnen, want hij heeft namelijk niet de mogelijkheid om de id-kaart te controleren op authenticiteit.

Ten eerste: is het wel nodig dat de uitsmijter deze gegevens kan inzien (zoals bsn, etc), voor enkel een leeftijds check? En waarom zou de uitsmijter de exacte leeftijd van Bob moeten weten? Een groen vinkje zal toch genoeg moeten zijn als Bob ouder is dan 18? Ten tweede: Hoe kan een uitsmijter in een korte tijd controleren of een id vervalst is?

Situatie met SSI

Bob is 17 jaar en wil een avondje stappen. De uitsmijter wil bij de ingang controleren of Bob 18 jaar of ouder is om naar binnen te mogen. De uitsmijter vraagt aan Bob’s om zijn leeftijd verifiëren en wijst naar een bord met een QR-code. Bob scant de QR-code met zijn telefoon en krijgt in zijn wallet een aanvraag om zijn leeftijd, in de vorm van een zero-knowledge proof, te verifiëren. Bob accepteert de aanvraag, de software checkt of zijn leeftijd hoger of gelijk is aan 18 jaar en wordt er gekeken of de credential authentiek is met de digitale handtekening op de blockchain. De credential is authentiek en omdat Bob 17 jaar is wordt er een rood kruis weergeven in plaats van een groen vinkje. Ondanks dat de uitsmijter niet exact weet hoe oud Bob is, weet hij wel dat Bob jonger is dan 18. Bob wordt daarom weggestuurd, jammer Bob.

  • Bob is in dit geval de holder en heeft in zijn wallet een id-kaart als digitale credential.
  • De gemeente heeft de digitale credential (de id-kaart) verstrekt aan Bob en de digitale handtekening geplaatst op de blockchain. De gemeente is dus de issuer
  • De bar (waar de uitsmijter voor werkt) wil controleren of de credential van Bob legitiem en of Bob 18 jaar of ouder is. Het hotel is dus de verifier

Nadelen

Self Sovereign Identity heeft (helaas) ook nadelen. Een groot nadeel is bijvoorbeeld wegeving dat vereist dat sommige instanties data bewaren voor een bepaalde tijd. Door deze wetten is het in theorie onmogelijk om als gebruiker je eigen data te blokkeren of in te trekken bij derde partijen (zoals in voorbeeld 1). Om dit op te lossen zou er bijvoorbeeld een wetsvoorstel moeten komen, dat holders verplicht stelt om verzoeken van derde partijen minimaal voor een x aantal jaren te verstrekken.

Een tweede nadeel van SSI is de transitie van een niet-SSI-wereld naar een SSI-wereld. De (persoonlijke)data van gebruikers dat nu nog beheert wordt door de derde partij, moet in de toekomst overgezet worden naar de persoonlijke wallets. Deze transitieperiode kan voor vele bedrijven een reden zijn om niet “even snel” een SSI oplossing te implementeren.

Dan blijft er nog een belangrijk vraagstuk over: kan SSI te alle tijde ethisch worden ingezet? Hier kom ik later nog op terug in een andere blog post.

Conclusie

Hopelijk heb je nu een iets beter beeld gekregen over het principe Self Sovereign Identity en de eventuele potentie. SSI is zeker een toekomstbestendig concept dat problemen aanpakt die universeel en toepasbaar zijn in verschillende industrieën. Met steeds meer bedrijven die SSI gebruiken, zal het sneeuwbaleffect van adoptie toenemen - waardoor wijdverspreide SSI binnenkort een realiteit kan worden.

Voor meer informatie over SSI, zie de volgende links:

Referenties