Deze serie blogs richt zich op self-sovereign identity (SSI). Deze blog legt uit wat SSI is, hoe de basisarchitectuur eruit ziet en wat het voordeel is van de SSI architectuur wanneer deze ingezet wordt als implementatie van PDM (personal data management). In de eerste blog richtten we ons op waarom SSI is ontstaan. In de derde blog geven we enkele voorbeelden van use cases waarbij SSI een belangrijke rol speelt.
De SSI principes
Een self-sovereign identiteit, zoals de naam suggereert, stelt gebruikers in staat de ultieme controle te hebben over hun eigen persoonlijke gegevens. De gebruiker, en zij alleen, kan beslissen welke gegevens ze deelt en met wie. De definitie van SSI kan niet volledig in één zin beschreven worden. Er zijn echter enkele richtlijnen die helpen beschrijven wat SSI zou moeten zijn.
De bekendste zijn waarschijnlijk de tien SSI-principes van Christopher Allen [bron], waaronder:
- Gebruikerscontrole bij het delen van gegevens
- Privacy
- Transparantie van algoritmen
- Interoperabiliteit
- Overdraagbaarheid van gegevens
- Gegevensminimalisatie
Op basis van deze en andere principes is een SSI-architectuur ontstaan die momenteel wordt geïmplementeerd in verschillende voorbeelden en versies van SSI. Merk op dat deze principes sterk overeenkomen met de personal data management (PDM, soms in Nederland ook regie op persoonlijke gegevens genoemd) principes welke bijvoorbeeld door MyData worden opgevolgd. SSI ligt dan ook in het verlengde van PDM, het verschil zit in hoe data gedeeld wordt (daarover later meer) en we zullen ook zien in blog 3 dat er een aantal PDM oplossingen ook als SSI gezien kunnen worden. In deze blog richten we ons op deze architectuur om uit te leggen wat SSI is.
De 3 hoofdrollen van de SSI-architectuur
Er zijn drie hoofdrollen in de SSI-architectuur: de data bron (issuer of uitgever van de data), de data afnemer (verifier of controleur van de data) en de gebruiker. De gebruiker staat in het centrum van haar gegevens en heeft volledige controle over wat er met haar gegevens gebeurt.
De data bron is de bron van de gegevens van de gebruiker en geeft haar persoonlijke en niet-persoonlijke informatie (die vaak “credentials” worden genoemd). De data afnemer zal de informatie van de gebruiker vragen, en als zij deze wil delen, zal de data afnemer deze van haar ontvangen en daarna kunnen valideren. Voor het standpunt van de gebruiker kunnen er meerdere data bronnen, data afnemers en registers zijn.
De afbeelding beschrijft de basis SSI-stroom. Stap 1) De gebruiker (holder) vraagt haar informatie op bij de data bron (issuer) en de data bron stuurt de ondertekende informatie naar de gebruiker. Stap 2) Een data afnemer (verifier) vraagt bepaalde informatie (credential) aan bij de gebruiker, de gebruiker kan een deel van haar informatie die door de data bron ondertekend is, aan de data afnemer verstrekken. Stap 3) De data afnemer controleert de handtekening van de informatie met behulp van het register (registry). Een belangrijk verschil tussen SSI en PDM zit in stap 2: bij SSI zal de data nooit rechtstreeks via de data bron naar de data afnemer gaan, maar altijd via de gebruiker: hierdoor weet de data bron nooit bij welke data afnemer de gebruiker haar data deelt. Bij PDM kan het ook voorkomen dat de data rechtstreeks verzonden wordt met toestemming van de gebruiker (wat weer meer lijkt op een user-centric federatieve identiteit, zie ook deel 1.
Een ander voordeel van SSI is dat de gebruiker er voor kan kiezen om slechts een deel van haar gegevens te delen met de data afnemer, terwijl dat deel nog steeds verifieerbaar is uitgegeven door de data bron.
Data verifiëren
Stap 3, de verificatie van de gegevens van de gebruiker, gebeurt aan de hand van de openbare gegevens van de data bron. Deze bevatten informatie zoals een openbare sleutel om de digitale handtekening van de informatie te controleren. Deze publieke sleutel van de data bron, of in het algemeen, de gebruikte publieke-privé sleutelcryptografie, is een belangrijk onderdeel van de beveiliging van SSI. Deze public-private key encryptie wordt gebruikt in meer digitale omgevingen om vertrouwen te creëren tussen gebruikers of organisaties. Simpel gezegd, een openbare sleutel, waarvan iedereen op de hoogte kan zijn, wordt gebruikt door een data afnemer of gebruiker om een handtekening op de informatie van een data bron te valideren. De privé sleutel, die alleen bekend is bij de data bron, wordt gebruikt om een digitale handtekening op de informatie van de gebruiker te zetten, alvorens deze wordt uitgegeven.
Het register, de extra rol
In veel SSI-omgevingen wordt een extra rol geïntroduceerd: die van het register (registry). Het register houdt een lijst bij van alle (of een aantal) bekende data bronnen en hun openbaar gegevens. Een voordeel van het register is dat hierdoor data afnemers makkelijker valideren of informatie inderdaad van die gebruiker is en door die data bron is uitgegeven. Zonder het register moet de data afnemer de data bron om zijn openbare gegevens vragen wanneer de data afnemer informatie van die data bron wil valideren. Met een register hoeft de data afnemer niet elke data bron te vragen naar hun openbare gegevens, maar wordt het register gebruikt.
Het register introduceert echter ook een vertrouwensprobleem. De data afnemer moet erop vertrouwen dat het register eerlijk is wat betreft de openbare gegevens van de data bronnenzijn macht om valse gegevens te verstrekken niet misbruikt.
In deze blog keken we naar de architectuur van SSI en twee grote voordelen van SSI: de mogelijkheid om maar een deel van de data te delen terwijl deze nog wel verifieerbaar is en het cryptografische mechanisme dat het mogelijk maakt voor partijen om SSI te gebruiken zonder dat de data bron de gegevens persoonlijk rechtstreeks aan de data afnemer hoeft te leveren. Dit draagt bij aan meer gebruikerscontrole, meer privacy en gegevensminimalisatie.