Die grootste ontwerpfout in ‘n toekomstige Internasionale Bestuurspermit (IDP) sou wees om elke verifieerder as dieselfde verifieerder te behandel. ‘n Polisiebeampte, ‘n motorverhuurkantoor, ‘n werkgewer en ‘n versekeraar vra nie dieselfde vraag nie — dus behoort hulle nie dieselfde antwoord te ontvang nie.
Een bestuurder. Een onderliggende reg om te ry. Een beursie. Maar vier heeltemal verskillende verifieerders:
- ‘n Polisiebeampte by die padkant
- ‘n Motorverhuurkantoor by aflewering
- ‘n Werkgewer wat vlootgeskiktheid nagaan
- ‘n Versekeraar wat ‘n eis hersien
As die toekomstige IDP dieselfde data aan al vier wys, het die stelsel reeds misluk. Nie omdat die geloofsbrief onseker is nie, maar omdat die openbaringsmodel te eenvoudig is.
Die standaardegemeenskap beweeg reeds weg van daardie eenvoudige model. W3C se verifieerbare-geloofsbriewe-werk beskryf die ekosisteem rondom uitreiers, houers en verifieerders, met werkgewers en webwerwe as voorbeelde van verifieerders. Die EU se mobiele bestuurslisensie-werk behandel reeds padkantkontrolle en motorverhuring as aparte verifikasiesituasies, insluitend afgeleë vooruitdeling vir huurings en persoonlike kontrole vir polisie. Die argitektuur is reeds ontwerp vir verskeie verifieerder-tipes. Die fout sou wees om die gebruikerservaring te ontwerp asof slegs een tipe bestaan.
Waarom die Fisiese Kaart Ons Geleer Het om Verkeerd te Dink
‘n Fisiese lisensie het ons geleer om alles te wys. Jy oorhandig die kaart. Die ander persoon sien wat op die kaart is. Dit is die hele interaksie.
Daardie benadering is aanvaarbaar in ‘n papierêre wêreld omdat daar geen alternatief is nie. Dit word onaanvaarbaar in ‘n digitale een.
Die W3C VC Data Model 2.0 sê direk: ‘n bestuurslisensie kan ID-nommer, lengte, gewig, verjaarsdag en tuisadres bevat — maar dit kan steeds baie meer wees as wat nodig is vir ‘n gegewe transaksie. Sleutelpunte uit huidige standaarde:
- W3C beste praktyk: ondersteun selektiewe openbaring, en versoek slegs wat streng nodig is
- EU-databeskermingsleiding: verwerking moet beperk wees tot gespesifiseerde doeleindes, en die verwerkte data moet noodsaaklik en proporsioneel wees
- Die eerste beginsel van ‘n toekomstige IDP: dieselfde geloofsbrief beteken nie dieselfde reg om te inspekteer nie
Die Regte Model Is Beleidsgebaseerde Openbaring
As jy ‘n ernstige argitektuur wil hê, is die regte model nader aan attribuutgebaseerde toegangsbeheer as aan digitale kaartaanbieding.
NIST SP 800-205 definieer toegangsbeheersbesluite as evaluasies van eienskappe wat verband hou met die subjek, objek, versoekte operasie en omgewingstoestande, teen beleid. Dit is presies die regte struktuur vir ‘n toekomstige IDP:
- Subjek: die bestuurder
- Objek: die versoekte datavelde
- Aksie: nie “sien lisensie” in die abstrak nie, maar iets spesifieks soos “verifieer reg om kategorie B by die padkant te bestuur” of “verifieer huurgeskiktheid vir ‘n bespreking”
- Omgewing: padkant, verhuurkantoor, afgeleë voorafkontrole, vlootonboarding en na-verlies-eishersien is verskillende omgewings en behoort tot verskillende besluite te lei
NIST merk ook op dat eienskapstelsels granulariteit, bestuur en meganismes vir vermindering, groepering en minimalisering van eienskappe benodig.
Die toekomstige IDP behoort dus nie te vra nie: Kan hierdie verifieerder die lisensie lees? Dit behoort te vra: Watter eise mag hierdie verifieerder ontvang, vir watter beoogde gebruik, in hierdie omgewing, met watter bewaringreëls?
‘n Verifieerder Moet Homself Identifiseer Voor hy Enigiets Versoek
Die toekomstige IDP behoort nie te begin met die beursie wat data wys nie. Dit behoort te begin met die verifieerder wat bewys wie hy is.
Die EUDI-argitektuur is duidelik hieroor. Vertroude partye moet:
- Registreer watter eienskappe hulle van plan is om te versoek en vir watter doel
- Toegangssertifikate ontvang
- By die beursie verifieer voor enige openbaring
- Teen hul geregistreerde omvang nagegaan word, waar registrasie-inligting beskikbaar is
Die gebruiker kan dan sien wie vra, wat gevra word en of die versoek binne die geregistreerde omvang val.
ETSI se huidige beursie-vertroude-party-sertifikaatwerk maak dit meer konkreet. ‘n Beursie-vertroude-party-registrasiesertifikaat kan die vertroude party se beoogde gebruik en die eienskappe wat dit geregistreer het om te versoek, beskryf. Die verwante toegangssertifikaat bestaan om te verseker dat die versoek van ‘n wettige, gemagtigde party kom. ETSI sluit ook vertroude-party-metadata in soos:
- Handelsnaam
- Ondersteunings-URI
- Beoogde gebruik
- Regte
- Registrasie-URI
- Toesighoudende-owerheid-inligting
Die tweede beginsel van ‘n toekomstige IDP: geen verifieerder-identiteit, geen openbaring.
Waarom Toestemmingsskerms Nie Voldoende Is Nie
Daar is nog ‘n fout hier: om gebruikergoedkeuring te behandel as dieselfde ding as wettige legitimiteit.
Die EUDI-argitektuur sê uitdruklik dat gebruikergoedkeuring om eienskappe aan te bied nie as wettige gronde vir die vertroude party se verwerking van persoonlike data behandel moet word nie. Die vertroude party moet steeds sy eie wettige basis hê. EUDI vereis ook gebruikergoedkeuring in alle gebruiksgevalle, insluitend gevalle waar die vertroude party deel kan wees van wetstoepassers of ‘n ander regeringsagentskap.
‘n Goeie beursieskoppelvlak kan help, maar dit kan nie verifieerder-oortreding op sy eie oplos nie. Die reël moet bestaan voor die koppelvlak.
‘n Toekomstige IDP benodig daarom beide:
- Kriptografiese verifieerder-verifikasie om te bevestig wie vra
- Beleidsbeperkings op wat daardie verifieerder-kategorie mag versoek
Sonder beide word “gebruikerkeuse” ‘n manier om beleidsversuim op die individu te skuif.
1. Polisie: Verifieer die Reg om te Ry, Nie die Hele Persoon Nie
Die polisie-padkantscenario is die mees gefokuste een.
Die EU mDL-handleiding beskryf dit direk: polisie of ander amptenare kontroleer die lisensie wanneer vereis, insluitend lisensiegeldigheid en voertuigregte. In die gebruikerreis verifieer die beampte die lisensie deur ‘n QR-geaktiveerde vloei, Bluetooth, Wi-Fi Aware of NFC. Dit is ‘n gefokuste verifikasietaak:
- Is hierdie persoon die houer?
- Is die geloofsbrief geldig?
- Watter voertuigregte en beperkings geld?
By verstek toegelaat:
- Naam
- Portret
- Lisensie-status
- Uitreiking- en vervaldatums
- Kategorieë
- Ryrelevante beperkings
- Uitreier en jurisdiksie
- Varsheid/statusresultaat
By verstek nie toegelaat nie:
- Tuisadres
- Interne identifiseerders wat nie nodig is vir padkantgebruik nie
- Nie-verwante eienskappe van ander attestasies
- Historiese aanbieding-logs
- Kommersiële metadata
AAMVA se implementeringsleiding versterk die portretpunt: as die portret versoek word en enige ander element vrygestel word, behoort die portret gedeel te word sodat die verifieerder die data kan koppel aan die persoon wat dit aanbied. Dieselfde leiding sê ook dat belanghebbendes nie mDL-houers of mDL-gebruik mag naspoor nie, behalwe waar dit deur die wet vereis word.
Die polisiegeval gaan nie oor die staat wat alles ontvang nie. Dit gaan oor die staat wat die ry-spesifieke data ontvang wat nodig is vir padkanthandhawing. Dit is ‘n belangrike verskil.
2. Verhuurkantore: Geskiktheid, Identiteitsooreenstemming en Niks Onnodig Nie
Die huurigeval is meer gedetailleerd omdat daar werklik twee oomblikke is: afgeleë voorafkontrole voor aankoms, en aflewering wanneer ‘n persoon of kiosk die sleutels oorhandig.
Die EU mDL-handleiding modelleer reeds beide. ‘n Motorverhuurkundige mag die mDL saam met bewys van identiteit tydens bespreking versoek, die attestasies valideer en later die kliënt in persoon by aflewering verifieer voor die voertuig vrygestel word. Gebruikers kan hul mDL’s met motorverhuurmaatskappye deel, hetsy persoonlik of op afstand vooraf.
‘n Verhuurkantoor hoef nie primêr ‘n voorval te ondersoek nie. Dit moet besluit: Kan ek hierdie voertuig aan hierdie kliënt verhuur onder hierdie bespreking en beleid?
Afgeleë voorafkontrole behoort in te sluit:
- Identiteitsverbinding
- Portret of ekwivalente identiteitsverbindingselement
- Relevante voertuigkategorie
- Uitreiking- en vervaldatums
- Huidige geldigheid
- Moontlik ‘n ouderdomsdrempel of ouderdomsband
Aflewering behoort te bevestig:
- Die houer is dieselfde persoon wat die voorafkontrole voltooi het
- Huidige geldigheid
- Relevante regte
Nie by verstek nodig nie:
- Volledige tuisadres wanneer ‘n besprekingsprofiel reeds kontakbesonderhede bevat
- Volledige geboortedatum waar ouderdom-oor of ouderdomsband voldoende is
- Nie-verwante identiteitseienskappe
- Herhaalde heraanbieding van die volledige geloofsbrief as ‘n besprekingsattestasie reeds bestaan
NIST se huidige mDL-argitektuur wys die vertroude party wat DCQL gebruik om slegs die benodigde eienskappe te versoek, en sê uitdruklik dat dit dataminimering en houerstoestemming ondersteun deur die versoek te struktureer eerder as om die geloofsbrief as ‘n enkele eenheid te behandel. AAMVA voeg by dat die toepassing duidelik moet wys watter data versoek is en of die verifieerder die inligting beoog om te behou.
3. Werkgewers: ‘n Verifieerder-Kategorie, Nie ‘n Opening in Volle Identiteit Nie
W3C se oorsig gebruik ‘n werkgewer se digitale stelsel wat ‘n universiteitsgraad nagaan as ‘n verifieerder-voorbeeld. Dit herinner ons dat werkgewerverifikasie reeds ‘n erkende patroon in geloofsbrief-ekostelsels is.
‘n Werkgewer of vlootoperateur mag wettiglik moet weet:
- Of ‘n werknemer tans geregtig is om sekere voertuigkategorieë te bestuur
- Of sleutelbeperkings bestaan
- Of die reg geldig bly
Dit is ‘n werklike besigheidsbehoefte. Maar dit regverdig nie outomaties permanente toegang tot die hele bestuursgeloofsbrief, die volledige identiteitsdata, of ‘n voortdurende stroom van herhaalde aanbiedings nie.
NIST waarsku dat die gereelde oordra van ‘n herbruikbare identifiseerder en die kondisionering van gebruikers om herhaaldelik ‘n identiteitsdraende geloofsbrief aan te bied onwenslik is, en sê dat alledaagse verifikasie op tegnologieë moet steun wat ontwerp is vir verifikasie, soos wagsleutels. NIST verkies plaaslike toestelverifikasie bo bediener-kant biometriese ooreenstemming omdat dit privaatheid beter bewaar.
‘n Toekomstige IDP behoort nie ‘n werkplektoegangsbadge te word nie.
Vir werkgewer- en vlootgebruik is die regte patroon gewoonlik:
- ‘n Werkrelevante regskontrole
- Miskien ‘n periodieke nalewingsattestasie
- Miskien ‘n bewering dat die houer geldig bly vir gespesifiseerde kategorieë
- Maar nie ‘n verstekooordrag van alle lisensiedata elke keer as die werknemer by ‘n stelsel aanmeld of ‘n skof begin nie
Vlootnakoming is ‘n aparte vertroude-party-kategorie, met ‘n aparte beoogde gebruik en ‘n aparte openbaringsprofiel.
4. Versekeraars: Eise Is Nie Toestemming vir Voortdurende Sigbaarheid Nie
Die versekeringgeval is dikwels werklik. In die EU mDL-gebruiksgeval-materiaal verskyn versekeraars indirek in die huurscenario: versekeringsmaatskappye vereis dat motorverhuurmaatskappye nagaan of die persoon wat die motor huur die reg het om te ry. Versekering beïnvloed reeds die bestuursverwerkingsvloei.
Maar dit beteken nie dat ‘n versekeraar dieselfde data as die polisie behoort te ontvang nie, of ‘n permanente reg om toegang tot die geloofsbrief te kry.
‘n Toekomstige IDP behoort versekeraars as ‘n aparte verifieerder-kategorie met aparte beoogde gebruike te behandel:
- Onderskrywing
- Huurrisikoverifikasie
- Na-verlies-eishantering
- Bedroghersiening
Dit is nie dieselfde doel nie. Onder EU-databeskermingsbeginsels moet persoonlike data ingesamel word vir gespesifiseerde doeleindes en beperk word tot wat noodsaaklik en proporsioneel is vir daardie doel. W3C se VC-leiding bereik dieselfde gevolgtrekking tegnies: verifieerders behoort slegs wat streng nodig is te versoek.
Wettige, gebeurtenis-spesifieke voorbeelde:
- Bewys dat die lisensie geldig was op die relevante oomblik
- Bewys van relevante voertuiekreg
- Bewys van identiteitsverbinding waar nodig vir ‘n eis
- Eis-spesifieke openbaring
By verstek nie toegelaat nie:
- Aanhoudende toegang tot die onderliggende geloofsbrief
- Herhaalde generiese verifikasie elke keer as die kliënt met die versekeraar omgaan
- Gebruik van die bestuursgeloofsbrief as ‘n aanmeldsimbool
- Insameling van nie-verwante eienskappe
‘n Bestuursgeloofsbrief is nie ‘n monitoreringsintekening nie. En dit behoort nie stilweg een te word nie.
Waarom Tussengangers Sigbaar Moet Wees
Werklike markte behels tussengangers. Huurplatforms, vlootverkopers, werkgewer-MH-stelsels en versekeringseis-verwerkers tree dikwels deur derde partye op.
Die EUDI-argitektuur hanteer dit deur:
- Tussengangers as vertroude partye te behandel
- Van hulle te vereis om te registreer
- Van hulle te vereis dat eienskappe wat versoek word vir die tussengeplaasde vertroude party geregistreer word
- Beide die tussenganger en die eindvertroude party aan die gebruiker te wys
- Tussengangers te verbied om data oor die inhoud van die transaksie te stoor
‘n Toekomstige IDP behoort nooit ‘n patroon toe te laat waar die gebruiker glo dat hulle aan die verhuurmaatskappy openbaar, maar in werklikheid openbaar hulle aan ‘n onsigbare verifikasie-makelaar, analise-verwerker en eisverkoperketting.
ETSI help hier. Sy beursie-vertroude-party-sertifikaatmodel sluit ondersteunings-URI’s, beoogde gebruik, registrasie-URI’s en toesighoudende-owerheid-metadata in. Dit is die tipe masjienleesbare infrastruktuur wat nodig is vir gebruikers om te verstaan wie werklik aan die ander kant van die versoek is en waarheen om te gaan as hulle verwydering of korreksie wil hê.
Bewaring Is Deel van Toegangsbeheer
Die meeste besprekings oor selektiewe openbaring eindig te vroeg. Hulle fokus op wat openbaar word. Hulle fokus nie genoeg op hoe lank dit daarna bly nie.
Huidige leiding konvergeer reeds:
- AAMVA: die beursie moet die houer duidelik meedeel watter data versoek is en of die verifieerder van plan is om dit te behou; belanghebbendes moet nie houers of mDL-gebruik naspoor nie, behalwe waar dit deur die wet vereis word
- W3C: houersagteware behoort logs van inligting wat met verifieerders gedeel is te verskaf, sodat oortollige versoeke geïdentifiseer kan word
- EUDI: gebruikers behoort toegang te hê tot transaksielogs, verdagte versoeke te kan rapporteer en verwydering te kan versoek
Bewaringsklasse behoort deel van die openbaringsbeleid self te wees:
- Polisie padkant: geen bewaring by verstek buite wettige operasionele rekord nie
- Huurvoorafkontrole: transaksierekord verbind aan bespreking, nie ‘n herbruikbare identiteitskopie nie
- Werkgewer-vlootnakoming: nalewingsrekord of attestasieresultaat, nie rou geloofsbrief-data nie
- Versekeraar-eis: eisrekord beperk tot die eis, nie permanente toegang nie
‘n Toekomstige IDP wat bewaring ignoreer, is slegs gedeeltelik privaatbewarend.
Wat die Beursie Werklik Moet Besluit
As ek hierdie hele artikel tot een implementeringsreël moet reduseer, sou dit hierdie wees:
Die beursie behoort nie “Kan ek hierdie geloofsbrief aanbied?” te beantwoord nie. Dit behoort “Kan ek hierdie stel eise aan hierdie gevereenstaande verifieerder aanbied, vir hierdie beoogde gebruik, in hierdie konteks, onder hierdie bewaringsklasse?” te beantwoord.
Daardie besluit behoort ten minste deur hierdie insette gedryf te word:
- Verifieerder-identiteit
- Verifieerder-kategorie
- Beoogde gebruik
- Geregistreerde eienskap-omvang
- Openbaringsbeleid van die uitreier, indien teenwoordig
- Omgewing (padkant, aflewering, afgeleë, vloot, eis)
- Houergoedkeuring
- Toepaslike bewaringsbeleid
Die standaarde bevat reeds baie van die masjinerie hiervoor: selektiewe openbaring, vertroude-party-verifikasie, geregistreerde beoogde gebruik, toegangssertifikate, openbaringsbeleid-evaluasie en doelgebonde versoeke. Wat nog ontbreek, is die dissipline om daardie stukke as een samehangende openbaringsargitektuur te behandel.
Die Kernargument
Die toekomstige IDP behoort nie te vra of data openbaar kan word nie. Dit behoort te vra:
- Wie vra?
- Vir watter doel?
- Onder watter gesag?
- In watter konteks?
- Met watter bewaring-gevolge?
Polisie, verhuurkantore, werkgewers en versekeraars is nie vier logo’s aan die ander kant van ‘n versoek nie. Hulle is vier verskillende risikomodelle, vier verskillende regsontekste, vier verskillende redes om te vra — en hulle behoort vier verskillende openbaringstelle te produseer.
Dit is nie onnodige kompleksiteit nie. Dit is hoe ‘n moderne bestuursgeloofsbrief lyk wanneer dit ophou om elke verifieerder as dieselfde verifieerder te behandel.
Gepubliseer April 27, 2026 • 13m om te lees
