Politie, Verhuurbalie, Werkgevers, Verzekeraars: Waarom Zij Niet Dezelfde Gegevens Mogen Zien

De grootste ontwerpfout in een toekomstig Internationaal Rijbewijs (IR) zou zijn om elke verificateur als dezelfde verificateur te behandelen. Een politieagent, een verhuurbalie, een werkgever en een verzekeraar stellen niet dezelfde vraag — dus mogen zij niet hetzelfde antwoord ontvangen.

Één bestuurder. Één onderliggend rijrecht. Één wallet. Maar vier zeer verschillende verificateurs:

• Een politieagent langs de weg
• Een verhuurbalie bij het ophalen
• Een werkgever die de vlootgeschiktheid controleert
• Een verzekeraar die een schadeclaim beoordeelt

Als het toekomstige IR aan alle vier dezelfde gegevens toont, heeft het systeem al gefaald. Niet omdat de credential onveilig is, maar omdat het openbaarmakingsmodel te eenvoudig is.

De standaardengemeenschap beweegt zich al weg van dat eenvoudige model. Het verifiable-credentials-werk van het W3C beschrijft het ecosysteem rondom uitgevers, houders en verificateurs, waarbij werkgevers en websites als voorbeelden van verificateurs worden gebruikt. Het Europese werk rondom mobiele rijbewijzen behandelt wegcontroles en autoverhuur al als afzonderlijke verificatiescenario’s, inclusief vooraf gedeeld op afstand voor verhuur en persoonlijke controles voor de politie. De architectuur is al ontworpen voor meerdere typen verificateurs. De fout zou zijn om de gebruikerservaring te ontwerpen alsof er slechts één type bestaat.

Waarom de Fysieke Kaart Ons Verkeerd Heeft Leren Denken

Een fysiek rijbewijs heeft ons geconditioneerd tot een alles-tonen-aanpak. Je geeft de kaart af. De andere persoon ziet wat er op staat. Dat is de volledige interactie.

Die aanpak is aanvaardbaar in een papieren wereld omdat er geen alternatief is. In een digitale wereld wordt zij onaanvaardbaar.

Het W3C VC Data Model 2.0 stelt dit rechtstreeks: een rijbewijs kan een ID-nummer, lengte, gewicht, geboortedatum en thuisadres bevatten — maar dat kan voor een bepaalde transactie nog altijd veel meer zijn dan noodzakelijk. Kernpunten uit de huidige standaarden:

• W3C best practice: ondersteun selectieve openbaarmaking en vraag uitsluitend op wat strikt noodzakelijk is
• EU-gegevensbeschermingsrichtlijnen: verwerking moet beperkt blijven tot opgegeven doeleinden, en de verwerkte gegevens moeten noodzakelijk en evenredig zijn
• Het eerste beginsel van een toekomstig IR: dezelfde credential betekent niet hetzelfde recht op inzage

Het Juiste Model Is Op Beleid Gebaseerde Openbaarmaking

Als je een serieuze architectuur wilt, lijkt het juiste model meer op attribuutgebaseerde toegangscontrole dan op digitale kaartpresentatie.

NIST SP 800-205 definieert toegangscontrolebeslissingen als evaluaties van attributen die zijn gekoppeld aan het onderwerp, het object, de gevraagde handeling en de omgevingsomstandigheden, getoetst aan beleid. Dat is precies de juiste structuur voor een toekomstig IR:

• Onderwerp: de bestuurder
• Object: de gevraagde gegevensvelden
• Handeling: niet “rijbewijs inzien” in abstracte zin, maar iets specifieks zoals “rijbevoegdheid voor categorie B langs de weg verifiëren” of “verhuurgeschiktheid voor een boeking verifiëren”
• Omgeving: langs de weg, verhuurbalie, voorafgaande controle op afstand, vlootonboarding en schadebeoordeling achteraf zijn verschillende omgevingen en moeten tot verschillende beslissingen leiden

NIST merkt ook op dat attribuutsystemen granulariteit, governance en mechanismen voor reductie, groepering en minimalisering van attributen nodig hebben.

Het toekomstige IR moet dus niet de vraag stellen: Kan deze verificateur het rijbewijs inzien? Het moet vragen: Welke claims mag deze verificateur ontvangen, voor welk beoogd gebruik, in welke omgeving, en met welke bewaarregels?

Een Verificateur Moet Zich Identificeren Voordat Hij Iets Opvraagt

Het toekomstige IR moet niet beginnen met de wallet die gegevens toont. Het moet beginnen met de verificateur die bewijst wie hij is.

De EUDI-architectuur is hierover duidelijk. Vertrouwende partijen moeten:

• Registreren welke attributen zij van plan zijn op te vragen en voor welk doel
• Toegangscertificaten ontvangen
• Zich bij de wallet authenticeren vóór enige openbaarmaking
• Worden getoetst aan hun geregistreerde reikwijdte, voor zover registratiegegevens beschikbaar zijn

De gebruiker kan vervolgens zien wie er vraagt, wat er wordt gevraagd en of het verzoek binnen de geregistreerde reikwijdte valt.

Het huidige werk van ETSI aan wallet-vertrouwende-partij-certificaten maakt dit concreter. Een registratiecertificaat voor een wallet-vertrouwende partij kan het beoogde gebruik en de geregistreerde te vragen attributen beschrijven. Het bijbehorende toegangscertificaat bestaat om te garanderen dat het verzoek afkomstig is van een legitieme, geautoriseerde partij. ETSI omvat ook metadata van de vertrouwende partij, zoals:

• Handelsnaam
• Ondersteunings-URI
• Beoogd gebruik
• Bevoegdheden
• Register-URI
• Toezichthoudende-autoriteitsgegevens

Het tweede beginsel van een toekomstig IR: geen verificateur-identiteit, geen openbaarmaking.

Waarom Toestemmingsschermen Niet Voldoende Zijn

Er is nog een andere fout: gebruikersgoedkeuring gelijkstellen aan juridische rechtmatigheid.

De EUDI-architectuur stelt expliciet dat gebruikersgoedkeuring voor het presenteren van attributen niet mag worden behandeld als rechtmatige grondslag voor de verwerking van persoonsgegevens door de vertrouwende partij. De vertrouwende partij moet nog steeds een eigen rechtmatige grondslag hebben. EUDI vereist ook gebruikersgoedkeuring in alle gebruiksscenario’s, inclusief gevallen waarin de vertrouwende partij deel uitmaakt van handhavingsinstanties of een andere overheidsinstelling.

Een goede wallet-interface kan helpen, maar kan misbruik door verificateurs niet op zichzelf oplossen. De regel moet er zijn vóór de interface.

Een toekomstig IR heeft daarom beide nodig:

• Cryptografische verificateur-authenticatie om te bevestigen wie er vraagt
• Beleidsbeperkingen over wat die categorie van verificateurs mag opvragen

Zonder beide wordt “gebruikerskeuze” een manier om beleidsfalen op het individu af te schuiven.

1. Politie: Verifieer het Rijrecht, Niet de Volledige Identiteit

Het scenario van de politie langs de weg is het meest gefocuste.

De EU mDL-handleiding beschrijft dit rechtstreeks: politie of andere functionarissen controleren het rijbewijs indien vereist, inclusief de geldigheid van het rijbewijs en de voertuigbevoegdheden. In de gebruikersreis verifieert de agent het rijbewijs via een QR-gestuurde stroom, Bluetooth, Wi-Fi Aware of NFC. Dat is een gerichte verificatietaak:

• Is deze persoon de houder?
• Is de credential geldig?
• Welke voertuigbevoegdheden en beperkingen zijn van toepassing?

Standaard toegestaan:

• Naam
• Portretfoto
• Rijbewijsstatus
• Afgifte- en verloopdatums
• Categorieën
• Rijrelevante beperkingen
• Uitgever en jurisdictie
• Actualiserings-/statusresultaat

Standaard niet toegestaan:

• Thuisadres
• Interne identificatoren die niet nodig zijn voor gebruik langs de weg
• Niet-gerelateerde attributen uit andere attestaties
• Historische presentatielogboeken
• Commerciële metadata

De implementatierichtlijnen van AAMVA versterken het punt over de portretfoto: als de portretfoto wordt opgevraagd en een ander gegeven wordt vrijgegeven, dient de portretfoto te worden gedeeld zodat de verificateur de gegevens aan de presenterende persoon kan koppelen. Dezelfde richtlijnen stellen ook dat belanghebbenden mDL-houders of mDL-gebruik niet mogen traceren, tenzij wettelijk vereist.

Het politiescenario gaat er niet over dat de overheid alles ontvangt. Het gaat erom dat de overheid de rijspecifieke gegevens ontvangt die nodig zijn voor handhaving langs de weg. Dat is een belangrijk verschil.

2. Verhuurbalie: Geschiktheid, Identiteitscontrole en Niets Overbodigs

Het verhuurgeval is gedetailleerder, omdat er eigenlijk twee momenten zijn: een voorafgaande controle op afstand vóór aankomst, en het ophalen wanneer een persoon of kiosk de sleutels overhandigt.

De EU mDL-handleiding modelleert beide al. Een autoverhuurbedrijf mag het mDL samen met een identiteitsbewijs opvragen tijdens de boeking, de attestaties valideren en de klant later persoonlijk bij het ophalen verifiëren voordat het voertuig wordt vrijgegeven. Gebruikers kunnen hun mDL’s met autoverhuurbedrijven delen, zowel persoonlijk als vooraf op afstand.

Een verhuurbalie hoeft primair geen incident te onderzoeken. Ze moet beslissen: Kan ik dit voertuig verhuren aan deze klant op basis van deze boeking en dit beleid?

Voorafgaande controle op afstand dient te bevatten:

• Identiteitskoppeling
• Portretfoto of gelijkwaardig identiteitsbevestigend element
• Relevante voertuigcategorie
• Afgifte- en verloopdatums
• Huidige geldigheid
• Mogelijk een leeftijdsdrempel of leeftijdsband

Bij ophalen dient te worden bevestigd:

• De houder is dezelfde persoon die de voorafgaande controle heeft voltooid
• Huidige geldigheid
• Relevante bevoegdheden

Standaard niet nodig:

• Volledig thuisadres wanneer een boekingsprofiel al contactgegevens bevat
• Volledige geboortedatum wanneer een leeftijds-over- of leeftijdsbandbevestiging volstaat
• Niet-gerelateerde identiteitsattributen
• Herhaalde herpresentatie van de volledige credential als er al een boekingsattestatie bestaat

De huidige mDL-architectuur van NIST toont de vertrouwende partij die DCQL gebruikt om uitsluitend de benodigde attributen op te vragen, en stelt expliciet dat dit gegevensminimalisering en toestemming van de houder ondersteunt door het verzoek te structureren in plaats van de credential als één geheel te behandelen. AAMVA voegt hieraan toe dat de applicatie duidelijk moet aangeven welke gegevens zijn opgevraagd en of de verificateur van plan is de informatie te bewaren.

3. Werkgevers: Een Verificateurscategorie, Geen Toegang tot de Volledige Identiteit

Het overzicht van het W3C gebruikt het digitale systeem van een werkgever dat een universitair diploma controleert als voorbeeld van een verificateur. Dat herinnert ons eraan dat werkgeversverificatie al een erkend patroon is in credential-ecosystemen.

Een werkgever of vlootbeheerder mag legitiem weten:

• Of een werknemer momenteel gerechtigd is bepaalde voertuigcategorieën te besturen
• Of er relevante beperkingen bestaan
• Of de bevoegdheid nog geldig is

Dat is een reële bedrijfsbehoefte. Maar die rechtvaardigt niet automatisch permanente toegang tot de volledige rijcredential, alle identiteitsgegevens of een continue stroom van herhaalde presentaties.

NIST waarschuwt dat het frequent verzenden van een herbruikbare identificator en gebruikers conditioneren om herhaaldelijk een identiteitsdragende credential te presenteren onwenselijk is, en stelt dat dagelijkse authenticatie moet steunen op technologieën die zijn ontworpen voor authenticatie, zoals passkeys. NIST geeft de voorkeur aan lokale apparaatauthenticatie boven server-side biometrische matching, omdat dit de privacy beter beschermt.

Een toekomstig IR mag geen werkplektoegangsbadge worden.

Voor werkgever- en vlootgebruik is het juiste patroon doorgaans:

• Een functiegerelateerde bevoegdheidscontrole
• Mogelijk een periodieke nalevingsattestatie
• Mogelijk een claim dat de houder geldig blijft voor gespecificeerde categorieën
• Maar geen standaardoverdracht van alle rijbewijsgegevens elke keer dat de werknemer inlogt op een systeem of een dienst begint

Vlootnaleving is een afzonderlijke categorie van vertrouwende partij, met een afzonderlijk beoogd gebruik en een afzonderlijk openbaarmakingsprofiel.

4. Verzekeraars: Schadeclaims Zijn Geen Toestemming voor Voortdurende Inzage

Het verzekeringsscenario is vaak reëel. In het EU mDL-gebruiksscenariomateriaal verschijnen verzekeraars indirect in het verhuurgeval: verzekeringsmaatschappijen verplichten autoverhuurbedrijven te controleren of de huurder gerechtigd is het voertuig te besturen. Verzekeringen beïnvloeden de rijverificatiestroom al.

Maar dat betekent niet dat een verzekeraar dezelfde gegevens moet ontvangen als de politie, of een permanent recht op toegang tot de credential.

Een toekomstig IR moet verzekeraars behandelen als een afzonderlijke verificateurscategorie met afzonderlijke beoogde gebruiksdoeleinden:

• Acceptatie
• Verhuurrisicoverificatie
• Afhandeling van schades achteraf
• Fraudeonderzoek

Dat zijn niet hetzelfde doel. Onder EU-gegevensbeschermingsbeginselen moeten persoonsgegevens worden verzameld voor gespecificeerde doeleinden en beperkt blijven tot wat noodzakelijk en evenredig is voor dat doel. De VC-richtlijnen van het W3C bereiken technisch dezelfde conclusie: verificateurs mogen uitsluitend opvragen wat strikt noodzakelijk is.

Legitieme, gebeurtenisspecifieke voorbeelden:

• Bewijs dat het rijbewijs geldig was op het relevante moment
• Bewijs van relevante voertuigbevoegdheid
• Bewijs van identiteitskoppeling waar nodig voor een claim
• Claimspecifieke openbaarmaking

Standaard niet toegestaan:

• Permanente toegang tot de onderliggende credential
• Herhaalde generieke verificatie elke keer dat de klant contact heeft met de verzekeraar
• Gebruik van de rijcredential als inlogtoken
• Verzameling van niet-gerelateerde attributen

Een rijcredential is geen bewakingsabonnement. En dat mag het stilletjes ook niet worden.

Waarom Tussenpersonen Zichtbaar Moeten Zijn

Echte markten kennen tussenpersonen. Verhuurplatformen, vlootleveranciers, HR-systemen van werkgevers en schadebehandelaars van verzekeraars handelen vaak via derden.

De EUDI-architectuur pakt dit aan door:

• Tussenpersonen te behandelen als vertrouwende partijen
• Registratie van hen te vereisen
• Te vereisen dat attributen die worden opgevraagd namens de eindvertrouwende partij geregistreerd zijn
• Zowel de tussenpersoon als de eindvertrouwende partij aan de gebruiker te tonen
• Tussenpersonen te verbieden gegevens over de inhoud van de transactie op te slaan

Een toekomstig IR mag nooit een patroon toestaan waarbij de gebruiker denkt te openbaren aan het verhuurbedrijf, terwijl in werkelijkheid wordt geopenbaard aan een onzichtbare keten van verificatiemakelaars, analyseverwerkers en claimbeheerders.

ETSI helpt hier. Het wallet-vertrouwende-partij-certificaatmodel van ETSI omvat ondersteunings-URI’s, beoogd gebruik, register-URI’s en metadata van de toezichthoudende autoriteit. Dat is het soort machine-leesbare infrastructuur dat nodig is opdat gebruikers begrijpen wie er daadwerkelijk aan de andere kant van het verzoek staat en waar ze terecht kunnen als ze verwijdering of correctie willen.

Bewaring Is Onderdeel van Toegangscontrole

De meeste discussies over selectieve openbaarmaking eindigen te vroeg. Ze richten zich op wat er wordt geopenbaard. Ze richten zich onvoldoende op hoe lang het daarna bewaard blijft.

De huidige richtlijnen convergeren al:

• AAMVA: de wallet moet de houder duidelijk mededelen welke gegevens zijn opgevraagd en of de verificateur van plan is ze te bewaren; belanghebbenden mogen houders of mDL-gebruik niet traceren, tenzij wettelijk vereist
• W3C: houdersoftware moet logboeken bijhouden van gegevens die zijn gedeeld met verificateurs, zodat buitensporige verzoeken kunnen worden geïdentificeerd
• EUDI: gebruikers moeten transactielogboeken kunnen inzien, verdachte verzoeken kunnen melden en verwijdering kunnen aanvragen

Bewaarklasse moet onderdeel zijn van het openbaarmakingsbeleid zelf:

• Politie langs de weg: standaard geen bewaring buiten de wettelijk vereiste operationele registratie
• Verhuur voorafgaande controle: transactieregistratie gekoppeld aan de boeking, geen herbruikbare identiteitskopie
• Werkgever vlootnaleving: nalevingsregistratie of attestatieresultaat, geen ruwe credentialgegevens
• Verzekeringsschadeclaim: claimregistratie beperkt tot de claim, geen permanente toegang

Een toekomstig IR dat bewaring negeert, beschermt de privacy slechts gedeeltelijk.

Wat de Wallet Daadwerkelijk Moet Beslissen

Als ik dit hele artikel zou moeten terugbrengen tot één implementatieregel, zou dat deze zijn:

De wallet moet niet beantwoorden “Kan ik deze credential presenteren?” Ze moet beantwoorden “Kan ik deze set claims presenteren aan deze geauthenticeerde verificateur, voor dit beoogde gebruik, in deze context, onder deze bewaarklasse?”

Die beslissing moet worden gestuurd door ten minste deze invoergegevens:

• Verificateur-identiteit
• Verificateurscategorie
• Beoogd gebruik
• Geregistreerde attributenreikwijdte
• Openbaarmakingsbeleid van de uitgever, indien aanwezig
• Omgeving (langs de weg, ophalen, op afstand, vloot, claim)
• Goedkeuring van de houder
• Toepasselijk bewaarbeleid

De standaarden bevatten al veel van de benodigde mechanismen: selectieve openbaarmaking, authenticatie van vertrouwende partijen, geregistreerd beoogd gebruik, toegangscertificaten, evaluatie van openbaarmakingsbeleid en doelgebonden verzoeken. Wat nog ontbreekt is de discipline om die onderdelen te behandelen als één samenhangende openbaarmakingsarchitectuur.

Het Kernargument

Het toekomstige IR moet niet de vraag stellen of gegevens geopenbaard kunnen worden. Het moet vragen:

• Wie vraagt?
• Met welk doel?
• Op grond van welke bevoegdheid?
• In welke context?
• Met welke bewaarconsequenties?

Politie, verhuurbalie, werkgevers en verzekeraars zijn niet vier logo’s aan het andere einde van een verzoek. Het zijn vier verschillende risicomodellen, vier verschillende juridische contexten, vier verschillende redenen om te vragen — en zij moeten tot vier verschillende openbaarmakingssets leiden.

Dat is geen onnodige complexiteit. Dat is hoe een moderne rijcredential eruitziet wanneer zij stopt met elke verificateur te behandelen als dezelfde verificateur.