De Europese digitale identiteitswallet komt eraan, en met hem de plicht voor veel dienstverleners om hem te accepteren. Interessanter dan de plicht is wat hij mogelijk maakt: alleen vragen wat u werkelijk nodig heeft. Wij bouwen die koppeling naast uw bestaande inlogmiddelen, niet in plaats ervan.
Met de herziening van eIDAS (Verordening EU 2024/1183) krijgt elke lidstaat de opdracht om burgers en bedrijven een digitale identiteitswallet aan te bieden. De Europese lijn is dat die wallets eind 2026 beschikbaar zijn; Nederland werkt aan een eigen publieke wallet. Voor dienstverleners komt daar een acceptatieplicht achteraan, met een eigen tijdlijn die afhangt van de uitvoeringshandelingen. Belangrijk detail: die plicht gaat over erkende wallets in het algemeen, dus wachten op een specifieke wallet is geen strategie.
Wat dit buiten de plicht om interessant maakt, is de kant van de gegevensbeperking. Veel organisaties vragen bij het inloggen of bij een aanvraag meer dan ze nodig hebben, simpelweg omdat het middel niet anders kon. Met selectieve openbaarmaking kunt u de afgeleide vragen in plaats van het gegeven zelf: niet de geboortedatum maar of iemand achttien is, niet het volledige adres maar de gemeente. Minder vragen betekent minder bewaren en minder uitleggen.
Wij bouwen de kant van de accepterende partij: het verzoek dat u naar de wallet stuurt, het controleren van wat er terugkomt, en het koppelen aan de identiteit die u al in uw systeem heeft. Dat raakt vrijwel altijd uw bestaande inlogketen en soms uw koppelingen met andere systemen. Voor organisaties die daarnaast met informatiebeveiliging bezig zijn, richten we het zo in dat beide trajecten elkaar niet in de weg zitten.
Waar u begint, hangt af van waarvoor u identiteit gebruikt: inloggen, een enkel kenmerk controleren, of een dossier opbouwen. In het eerste gesprek bepalen we dat.
Een tweede route naar dezelfde identiteit in uw systeem. Voor uw gebruikers verandert er in eerste instantie niets: er komt een knop bij. Technisch is het ontwerpwerk vooral het koppelen — iemand die vandaag met een bestaand middel inlogt en morgen met een wallet, hoort dezelfde persoon te zijn en hetzelfde dossier te zien. Wij bouwen die route zo dat hij apart uit te zetten is, zodat wijzigingen in de standaarden uw bestaande dienstverlening niet raken.
Leeftijdsgrens, woonplaats, beroepsbevoegdheid, tekenbevoegdheid. In plaats van een document te vragen en op te slaan, vraagt u de bevestiging en bewaart u het antwoord. Dat scheelt u bewaartermijnen, uitleg en risico. Wij lopen daarvoor eerst uw formulieren langs: welk gegeven vraagt u, waarom, en wat is de afgeleide die u werkelijk nodig heeft. Die schoonmaak levert in de praktijk vaak meer op dan de wallet zelf.
Naast identiteit kunnen wallets verklaringen dragen die door een organisatie zijn afgegeven: een diploma, een lidmaatschap, een bevoegdheid, een klantstatus. Bent u de partij die zoiets afgeeft, dan bouwen wij de uitgiftekant; bent u de partij die het controleert, dan de controlekant. Vaak allebei, want organisaties die uitgeven willen doorgaans ook kunnen controleren wat anderen hebben afgegeven.
Een werkende koppeling die naast uw bestaande inlogmiddelen staat, met de documentatie die u nodig heeft om u als accepterende partij te laten registreren.
Vier situaties waarin het zinvol is hier nu naar te kijken in plaats van te wachten tot de datum in zicht komt.
Voor publieke dienstverleners en voor diensten die wettelijk sterke authenticatie moeten gebruiken, komt de plicht om erkende wallets te accepteren. Wie zijn identiteitslaag nu al uitbreidbaar maakt, hoeft dat straks niet onder tijdsdruk te doen.
Er staan velden op uw formulier waarvan niemand meer weet waarom ze er staan, en u bewaart documenten waar u eigenlijk alleen een bevestiging uit nodig had. Dat is nu een risico en met selectief delen straks onnodig.
Uittreksels, identiteitsbewijzen of diploma’s worden geupload en met de hand gecontroleerd. Dat is traag, foutgevoelig en levert u een bewaarplicht op voor gegevens die u liever niet had gehad.
Als de kennis over authenticatie door uw hele applicatie is uitgesmeerd, wordt elk nieuw inlogmiddel een verbouwing. Dat opruimen heeft nu al waarde en maakt de wallet straks een toevoeging in plaats van een project.
Waarvoor gebruikt u identiteit: inloggen, een kenmerk controleren, of een dossier opbouwen? Welke inlogmiddelen draaien er nu, en hoe is dat in uw applicatie belegd? Die laatste vraag bepaalt vaak de helft van het werk, want een verspreide inlogketen kost meer dan de wallet zelf.
Een werksessie waarin we per formulier en per veld bepalen: waarom vraagt u dit, is het noodzakelijk of wenselijk, en welke afgeleide volstaat. Noodzakelijk en wenselijk horen zich in uw software anders te gedragen, en dat onderscheid ontbreekt vrijwel altijd.
We werken in tweewekelijkse sprints. Eerst de identiteitslaag zo maken dat er een middel bij kan zonder dat u overal iets moet aanpassen, dan de walletroute zelf, dan de kenmerken. Uw eigen ontwikkelaars werken mee, want dit raakt de kern van uw applicatie.
De standaarden zijn er en er zijn proefopstellingen om tegenaan te testen, ruim voordat de publieke wallets breed beschikbaar zijn. We testen ook het pad waarin iemand geen wallet heeft of een gegeven weigert, want dat is het pad dat in de praktijk het vaakst wordt overgeslagen.
De documentatie voor uw registratie als accepterende partij, een overdracht aan uw team, en afspraken over wat er gebeurt als de standaarden of de nationale invulling wijzigen. Dat laatste is in dit dossier geen theoretisch scenario.
Wat productverantwoordelijken, architecten en privacy-functionarissen ons vragen voordat zij hieraan beginnen.
Een kennismaking van een half uur, vrijblijvend. Vertel welke gegevens u nu opvraagt en hoe uw inloggen is geregeld, dan zeggen we wat er als eerste zou moeten en wat kan wachten — ook als we uiteindelijk niet samenwerken.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
