Geen Terugkoppeling naar de Uitgever: Waarom het Toekomstige Digitale IRP bij elk Gebruik Niet mag Thuisbellen

Intrekking is het moeilijkste probleem bij elk toekomstig digitaal Internationaal Rijbewijs (IRP). De eenvoudigste manier om dit op te lossen is ook de gevaarlijkste: maak de uitgever een deelnemer bij elke afzonderlijke presentatie. Een modern grensoverschrijdend rijbewijs moet deze omweg standaard weigeren.

Bijna elk voorstel voor digitale identiteit bevat dezelfde geruststellende zin:

“Het credential kan onmiddellijk worden geverifieerd.”

Soms beschrijft die zin echte vooruitgang. Soms beschrijft het surveillance met een vriendelijkere gebruikersinterface.

De huidige gepubliceerde normen maken al duidelijk dat een verificateur de uitgever niet bij elke presentatie van een credential hoeft te contacteren:

• De huidige mDL-architectuur van NIST stelt dat een verificateur authenticiteit en integriteit kan valideren door de handtekening en publieke sleutels van de uitgever te vertrouwen, zonder enig direct contact met de uitgever.
• AAMVA bevestigt dat ISO/IEC 18013-5 ondersteuning vereist voor apparaatophaling en serverophaling slechts optioneel toestaat.
• AAMVA waarschuwt ook dat bij serverophaling de uitgevende instantie bij elk gebruik in realtime betrokken is — wat betekent dat zij technisch gezien kan vastleggen wanneer het credential wordt gebruikt, welke gegevens worden gedeeld, en zelfs de locatie kan afleiden via IP-analyse.

Dat is geen kleine voetnoot. Het is de centrale ontwerpvraag voor de volgende generatie grensoverschrijdende rijbewijzen.

De Gevaarlijke Omweg: Vier Vragen Samenvoegen in Één Netwerkoproep

Slechte architecturen bundelen vier zeer verschillende vragen in één live oproep aan de uitgever:

1. Is dit credential authentiek?
2. Is de persoon die het toont de rechtmatige houder?
3. Is het credential zelf nog geldig?
4. Is het onderliggende nationale rijrecht nog van kracht?

Een slecht ontworpen systeem beantwoordt alle vier door in realtime thuis te bellen. Een goed ontworpen systeem scheidt ze — omdat het niet hetzelfde probleem is en ze geen gemeenschappelijk mechanisme mogen delen.

Authenticiteit Moet Lokaal Worden Geverifieerd, Niet via het Netwerk

Een credential kan cryptografisch echt zijn zonder dat de uitgever de transactie ooit waarneemt.

• Het mDL-vertrouwensmodel van NIST stelt dat authenticiteit en integriteit worden gevalideerd op basis van de handtekening en publieke sleutels van de uitgever — geen live contact met de uitgever vereist.
• De Digital Trust Service van AAMVA bestaat juist om verificateurs toegang te geven tot geldige publieke sleutels van uitgevers zonder callbacks per transactie.

Ontwerpprincipe 1: Gebruik geen live connectiviteit om een probleem op te lossen dat handtekeningen al oplossen.

Als een verificateur vertrouwde uitgeverssleutels bezit en een standaardconforme presentatie ontvangt, is authenticiteit een lokale cryptografische controle, geen netwerkafhankelijkheid.

Houdersbinding Moet Lokaal Worden Bewezen, Niet Globaal Worden Gemeld

De tweede vraag — is dit de rechtmatige houder? — heeft ook een antwoord zonder netwerk.

De huidige EUDI-architectuur verplicht apparaatbinding voor PID’s en ISO/IEC 18013-5-attestaties. De verificateur vraagt de wallet een verse uitdaging te ondertekenen met de privésleutel die overeenkomt met de publieke sleutel in het credential:

• In ISO/IEC 18013-5 heet dit mdoc-authenticatie.
• In SD-JWT VC heet het sleutelbinding.

In beide gevallen wordt bezit lokaal en cryptografisch bewezen. Er hoeven nooit persoonsgegevens de uitgever te bereiken.

Ontwerpprincipe 2: Bewijs bezit lokaal. Bewijs identiteit niet globaal.

Een toekomstig IRP moet apparaatbinding, lokale houderauthenticatie en verificateur-uitdagingsrespons volledig benutten voordat enig uitgeversijdig mechanisme wordt overwogen.

Credentialstatus en Rijrechtstatus Zijn Twee Verschillende Dingen

Veel digitale-identiteitsontwerpen vertroebelen dit onderscheid, en dat is waar ze de fout ingaan.

De Bitstring Status List-specificatie van het W3C maakt het punt duidelijk: statusinformatie gekoppeld aan een verifieerbaar credential heeft betrekking op het verifieerbare credential zelf — niet noodzakelijkerwijs op het onderliggende reëlewereldrecht. Een digitaal credential kan worden ingetrokken omdat het ondertekenmechanisme werd gecompromitteerd, terwijl het onderliggende rijrecht volledig geldig blijft.

Een toekomstig IRP heeft daarom twee afzonderlijke statuslagen nodig:

• Credentialstatuslaag — voor het digitale credential of het presentatiekanaal zelf.
• Rijrechtslaag — voor het onderliggende nationale recht om te rijden.

Soms veranderen deze samen. Vaak niet. Een systeem dat ze samenvoegt, zal overreageren, meer gegevens blootleggen dan nodig, of beide.

Walletcompromittering Moet Via de Status Doorsijpelen — Niet Verificateur-Callbacks Activeren

Een toekomstig IRP heeft ook een duidelijk antwoord nodig op wat er gebeurt als een wallet wordt gecompromitteerd.

De EUDI-architectuur biedt dit:

• De walletprovider geeft Wallet Unit Attestations uit met intrekkingsinformatie.
• Walletintegriteit wordt periodiek opnieuw geverifieerd; als een wallet niet langer veilig is, wordt de attestatie ingetrokken.
• PID-providers moeten regelmatig controleren of de wallet is ingetrokken. Als dat zo is, trekken zij de PID in.
• Door de PID-status te verifiëren, verifieert de vertrouwende partij impliciet de walletstatus.

Dit is de gelaagdheid die een toekomstig IRP moet overnemen. Vraag niet elke verificateur om de walletprovider onafhankelijk te controleren. Laat walletcompromittering doorsijpelen via de bestaande credentialstatuspijplijn en laat verificateurs dat ene privacybeschermende kanaal raadplegen.

Drie Werkbare Intrekkingspatronen (Geen Callbacks Vereist)

EUDI vereist dat providers één van drie intrekkingsmethoden gebruiken:

• Kortlevende attestaties — geldig voor 24 uur of minder, waardoor intrekking overbodig wordt.
• Attestatiestatuslijst — een gepubliceerde lijst die verificateurs kunnen raadplegen.
• Attestatie-intrekkingslijst — een expliciete lijst van ingetrokken credentials.

Voor attestaties die langer dan 24 uur geldig zijn, vereist EUDI het insluiten van intrekkingsinformatie die het volgende bevat:

• Een URL waar vertrouwende partijen de statuslijst kunnen ophalen.
• Een identificator die het credential binnen die lijst lokaliseert.

Als betrouwbare intrekkingsinformatie niet beschikbaar is — bijvoorbeeld wanneer de vertrouwende partij offline is — instrueert EUDI de vertrouwende partij een risicoanalyse uit te voeren voordat het credential wordt geaccepteerd of geweigerd.

De conclusie: intrekking is geen enkelvoudig mechanisme, en zeker geen rechtvaardiging voor verplichte uitgevers-callbacks.

Kortlevend als Standaard, Langlevend Alleen Waar Noodzakelijk

Een van de meest effectieve privacymaatregelen in de gehele stack is ook de eenvoudigste: houd wat wordt gepresenteerd kortlevend.

• EUDI stelt dat attestaties die 24 uur of minder geldig zijn geen intrekkingsinfrastructuur vereisen — ze verlopen voordat intrekking relevant zou zijn.
• W3C stelt dat verifieerbare presentaties doorgaans kortlevend zijn en niet bedoeld voor langdurige opslag.
• NIST waarschuwt expliciet tegen het herhaaldelijk verzenden van herbruikbare identificatoren voor dagelijks gebruik. Dagelijkse authenticatie moet steunen op technologieën die daarvoor zijn gebouwd, zoals passkeys, niet op de herhaalde presentatie van een identiteitsrijke credential.
• NIST koos ook voor lokale apparaatauthenticatie boven biometrische matching aan de serverzijde, juist omdat lokale authenticatie privacy beschermt en operationeel efficiënter is.

Ontwerpprincipe 3: Het basiscredential mag een gemiddelde geldigheidsperiode hebben, maar de presentatie zelf moet kortlevend, verificateurspecifiek en niet-herbruikbaar zijn.

Statuslijsten Zijn het Juiste Standaardmechanisme

Als u niet alles kortlevend kunt maken, heeft u statusinfrastructuur nodig — en de statuslijst is de juiste standaard.

De Bitstring Status List v1.0 van W3C beschrijft een privacybeschermend, ruimte-efficiënt en hoogpresterend mechanisme voor het publiceren van statusgegevens zoals opschorting of intrekking. Belangrijke eigenschappen zijn:

• Elke uitgever beheert een lijst voor de credentials die hij heeft uitgegeven.
• Het formaat comprimeert goed, omdat de meeste credentials niet worden ingetrokken.
• De standaard lijstgrootte is 131.072 vermeldingen, wat volgens W3C in de gemiddelde situatie voldoende groepsprivacy biedt.
• Grotere lijsten kunnen worden gebruikt waar sterkere groepsprivacy vereist is.

Dit verschuift de vraag van:

“Kan ik de uitgever nu over deze gebruiker bevragen?”

naar:

“Beschik ik al over een recente genoeg privacybeschermende statuslijst om lokaal een beslissing te nemen?”

Dat is een veel betere vraag — zowel technisch als politiek.

“Niet Thuisbellen” Is een Downloadpatroon, Geen Slogan

De belangrijkste regel in de privacyrichtlijnen van EUDI is procedureel, niet filosofisch.

Vertrouwende partijen mogen niet de statuslijst opvragen bij elke presentatie van een credential. In plaats daarvan moeten zij:

• Elke nieuwe versie van de lijst eenmalig downloaden.
• Dit doen op een tijdstip en vanaf een locatie die geen verband houden met een gebruikerspresentatie.
• De lijst intern verspreiden binnen de organisatie van de vertrouwende partij.
• De lijst ophalen zonder de vertrouwende partij te authenticeren.

Dat is de operationele kern van verificatie zonder thuisbellen: vernieuw de status los van gebruikerspresentaties — nooit per persoon, nooit per transactie.

Deze ene ontwerpkeuze voorkomt dat de uitgever of statusprovider kan vaststellen welke verificateur welk credential op welk moment heeft gecontroleerd.

Groepsprivacy: De Vereiste die de Meeste Ontwerpen Vergeten

Veel systemen prijzen selectieve openbaarmaking binnen de presentatie zelf, en negeren vervolgens stilletjes de privacy van statusopzoekingen. Dat is een significante tekortkoming.

De privacyvereisten van EUDI specificeren dat:

• Indexen in statuslijsten willekeurig moeten worden toegewezen, zodat de index zelf nooit een volgbaarheidssignaal wordt.
• Elke lijst een voldoende groot aantal credentials moet omvatten om groepsprivacy te garanderen.
• Als een lijst anders te klein zou zijn, moeten providers ongebruikte vermeldingen toevoegen om het werkelijke aantal credentials te verdoezelen.

Een toekomstig IRP kan niet claimen privacybeschermend te zijn op basis van selectieve openbaarmaking alleen. Als het intrekkingsmechanisme de presentatiegebeurtenis lekt, is het privacyontwerp onvolledig.

Offline Werking Is Geen Randgeval — Het Is een Kernvereiste

Elk reissysteem dat uitgaat van perfecte connectiviteit is slecht ontworpen.

• AAMVA bevestigt dat apparaatophaling werkt zonder externe connectiviteit voor zowel het apparaat van de houder als de lezer, en dat ISO/IEC 18013-5 vereist dat mDL’s apparaatophaling ondersteunen.
• EUDI accepteert dat vertrouwende partijen offline kunnen zijn en geen gecachede statuslijst beschikbaar hebben; in dat geval beveelt het een risicoanalyse aan alvorens een beslissing te nemen.

Accepteer deze afweging vroeg:

U kunt niet tegelijkertijd perfecte offline werking en perfecte realtime actualiteit hebben.

Elke architectuur die beide belooft zonder compromis is ofwel onnauwkeurig of herintroduceert stilletjes surveillance. Het juiste antwoord is om actualiteit te maken tot een beleidsinput, niet een universele netwerkafhankelijkheid.

Logboeken Zijn Waar Privacy Stilletjes Faalt

Zelfs een uitstekende statusarchitectuur kan worden ondermijnd door onzorgvuldig loggen.

• EUDI vereist dat instanties van vertrouwende partijen unieke elementen en tijdstempels zo snel mogelijk verwijderen zodra ze niet langer nodig zijn, en verbiedt het doorsturen ervan.
• AAMVA verbiedt belanghebbenden om mDL-houders of mDL-gebruik te volgen, behalve waar wettelijk vereist, vereist dat uitgevende instanties het delen van statische of langlevende metadata minimaliseren, en beperkt de toegang tot activiteitenlogboeken tot de houder.
• AAMVA vereist ook dat verwijdering op het apparaat loginformatie en metadata verwijdert die gebruiksgeschiedenis kunnen onthullen — en dat deze verwijdering offline mogelijk is.

Dit is protocolgedrag, geen administratieve huishouding. Een toekomstig IRP moet langlevende identificatoren, tijdstempels en logboeken behandelen als mogelijke volginstrumenten, tenzij expliciet anders bewezen.

Een Concrete Architectuur Zonder Thuisbellen voor het Toekomstige IRP

Door de principes samen te brengen, is dit wat het systeem daadwerkelijk moet doen:

1. Geef een apparaatgebonden basiscredential uit. Bind het credential aan sleutels die zijn beschermd in de beveiligde omgeving van de wallet — verplicht onder EUDI voor PID’s en ISO/IEC 18013-5-attestaties.
2. Vraag alleen wat nodig is, met een verse uitdaging. In een OpenID4VP-transactie laat een DCQL-query de wallet de houder zien welke attributen worden gevraagd, en geeft de verificateur een uitdaging om herhaling te voorkomen (conform de huidige mDL-architectuur van NIST).
3. Genereer een kortlevende presentatie, geen herbruikbare identificator. Elke presentatie moet specifiek zijn voor de verificateur, het verzoek en het moment.
4. Verifieer authenticiteit lokaal. Valideer uitgevershandtekeningen en publieke sleutels offline; de vertrouwensdienst van AAMVA is hier precies voor gebouwd.
5. Controleer de status via gecachede, afzonderlijk vernieuwde lijsten. Waar credentials te langlevend zijn om intrekking over te slaan, gebruik lokaal gecachede statuslijsten die op een schema worden vernieuwd dat losstaat van gebruikerspresentaties.
6. Pas een risicobeleid toe wanneer actualiteit niet beschikbaar is. Maak offline beslissingen tot expliciet verificateurbeleid, geen ongestructureerde gissingen.
7. Verwijder volggegevens actief. Gooi transactieunieke elementen en tijdstempels weg wanneer ze niet langer nodig zijn; bewaar geen logboeken die bewegingsgeschiedenis kunnen reconstrueren.

Dit is hoe een serieuze architectuur zonder thuisbellen eruitziet — gelaagd, privacybeschermend, cryptografisch lokaal en operationeel eerlijk over de offline werkelijkheid.

Drie Patronen die Ontwerpmatig Verboden Zouden Moeten Zijn

Een volwassen toekomstig IRP-ecosysteem zou deze moeten behandelen als architectuurfouten, niet als optimalisatiekeuzes:

• Verplichte uitgevers-callbacks bij elke presentatie. De eigen privacyrichtlijnen van AAMVA leggen uit waarom dit schadelijk is.
• Het rijbewijs gebruiken als routinematige aanmelding. NIST waarschuwt expliciet tegen het herhaaldelijk presenteren van identiteitsdragende credentials voor dagelijkse authenticatie.
• Het bewaren van identificatoren, tijdstempels en logboeken die presentatiegeschiedenis kunnen reconstrueren. Zowel EUDI als AAMVA vereisen het tegendeel.

Het Kernargument in Één Zin

Onmiddellijke verificatie mag geen toestemming worden voor surveillance aan de uitgeverskant.

Een toekomstig IRP moet in staat zijn om:

• Authenticiteit lokaal te bewijzen.
• Bezit lokaal te bewijzen.
• Actualiteit privé te controleren.
• De offline werkelijkheid te tolereren.
• Goed te functioneren wanneer perfecte informatie niet beschikbaar is.

Niets hiervan maakt het systeem zwakker. Het maakt het de moeite waard om op grote schaal in te zetten.

Op het moment dat een rijbewijs een instrument wordt om vast te leggen wie wat, waar en wanneer heeft getoond, houdt het op een veiligere versie van papier te zijn. Het wordt infrastructuur voor observatie.

Dat is precies wat het toekomstige IRP moet weigeren te worden.

Veelgestelde Vragen

Wat is “thuisbel-verificatie”?
Het is elk ontwerp waarbij een verificateur in realtime contact opneemt met de uitgever om een credential te valideren. Hoewel het authenticiteit en intrekking tegelijk oplost, kan de uitgever hierdoor elke presentatiegebeurtenis waarnemen.

Vereist ISO/IEC 18013-5 online contact met de uitgever?
Nee. AAMVA bevestigt dat ISO/IEC 18013-5 ondersteuning vereist voor apparaatophaling en serverophaling slechts optioneel toestaat.

Hoe kan intrekking werken zonder contact met de uitgever?
Via kortlevende credentials, attestatiestatuslijsten of attestatie-intrekkingslijsten — bij voorkeur met de vertrouwende partij die statusgegevens afzonderlijk van gebruikerspresentaties downloadt.

Waarom is “groepsprivacy” belangrijk voor statuslijsten?
Als een statuslijst te klein is of de indexen voorspelbaar zijn, kan een statusopzoekverzoek onthullen welk specifiek credential zojuist is gepresenteerd. Willekeurige indexen en grote lijsten voorkomen dit.

Is offline verificatie echt praktisch?
Ja — en normalisatie-instanties zoals AAMVA en EUDI vereisen dit expliciet. De afweging is dat perfecte realtime actualiteit onverenigbaar is met perfecte offline werking, dus actualiteit moet een beleidsbeslissing worden, geen harde afhankelijkheid.