MijnBesluit/docs/Identiteit.md

Wie is wie: dubbele profielen, claimen en samenvoegen

Dit document legt vast hoe MijnBesluit omgaat met de vraag "is dit dezelfde persoon?". Het is geschreven na een ontwerpgesprek op 15 september 2026, omdat de keuzes hier niet vanzelfsprekend zijn en de redenen erachter over een paar maanden niet meer uit de code te halen zijn.

Het probleem

Jonathan voegt zijn dochter Ysabeau toe als dochter. Zijn ex-partner voegt dezelfde Ysabeau toe, ook als dochter. Straks doen haar grootouders dat ook. Uiteindelijk maakt Ysabeau zelf een account en wil ze haar eigen profiel beheren — en als ze daar een foto zet, horen haar familie en vrienden die te zien.

Zonder maatregelen levert dat vier keer dezelfde persoon op.

De kern van de oplossing

Een niet-geclaimd profiel is een privé-aantekening van degene die hem maakte.

Wat Jonathan heeft aangemaakt is niet "Ysabeau", het is zijn aantekening over zijn dochter. Dat zijn ex haar eigen aantekening heeft is normaal en eerlijk. Dubbele profielen zijn vóór het claimen dus geen fout.

Het wordt pas een probleem op het moment dat Ysabeau zelf zegt: die ben ik. Daarmee verschuift de hele vraag — niet "hoe voorkom ik duplicaten bij het aanmaken", maar "hoe smelten ze samen op het moment van claimen".

Wat we bewust NIET doen

Niet zoeken op naam en geboortedatum. MyHeritage doet dat wel: je typt een naam en geboortedatum en krijgt "bedoelt u deze?". Dat werkt daar, maar het lekt. Wie mag zo'n vraag stellen? Als iemand "Ysabeau Flietstra, 12 maart 1998" intikt en het systeem zegt "die kennen we", dan weet die persoon nu dat ze hier zit. Met genoeg pogingen is dat een zoekmachine op mensen, en dat is precies wat MijnBesluit niet moet zijn.

Niet stilzwijgend koppelen op e-mailadres. (Wél vrágen; zie het hoofdstuk hieronder over de vraag bij het aanmelden. Het verschil is wie er beslist.) Dit zat er wél in, tot 15 september 2026: AddMemberAsync zocht een bestaand profiel op adres en hing dat aan je familie. Gevolg: wie het adres van iemand kende, zag meteen wat een ander over die persoon had ingevuld — naam, geboortedatum, profielfoto. Dat is dezelfde zoekmachine, via een andere deur.

De regel is nu: je hergebruikt alleen je eigen aantekeningen, nooit die van een ander. Voeg je iemand toe aan een tweede familie van jezelf, dan is dat wél hetzelfde profiel — anders zie je je eigen dochter twee keer.

Hoe het dan wel samenkomt

De uitnodiging is de match. Jonathan nodigt Ysabeau uit op haar adres, zijn ex doet dat ook, misschien op een ander adres. Ze neemt beide uitnodigingen aan. Daarmee heeft zíj gezegd dat beide profielen haar zijn — en zij is de enige die dat mag zeggen.

Concreet:

Situatie	Wat er gebeurt
Eerste uitnodiging, nog geen account	Er wordt een account gemaakt en het profiel wordt geclaimd. Zoals het altijd al ging.
Tweede uitnodiging, ingelogd	Het profiel uit de uitnodiging gaat op in het profiel dat je al hebt.
Tweede uitnodiging, niet ingelogd, adres is bekend	Geweigerd, met de uitleg dat je eerst moet inloggen. Een tweede account zou juist het probleem veroorzaken.

Dit werkt ook als beide ouders een ander e-mailadres van haar hadden: het adres speelt geen rol bij het koppelen, alleen de link die zij aanklikt.

De vraag bij het aanmelden (17 september 2026)

De uitnodiging is de match, maar hij is niet de enige weg. Wat er in de praktijk gebeurde: iemand voegt een vriend toe met zijn e-mailadres, die vriend maakt zelf een account aan, en dan staan er twee losse dingen naast elkaar die allebei over dezelfde man gaan. De vriend moet dan wachten tot er een uitnodiging komt die de ander misschien nooit verstuurt.

Automatisch koppelen op adres is daar niet het antwoord op, om twee redenen. Het lekt (zie hierboven), en een adres is geen identiteit: twee mensen kunnen er één delen - een echtpaar, een ouder die het adres van zijn kind gebruikt, een info@ - en sinds db/15 kunnen er ook meerdere aantekeningen met hetzelfde adres bestaan. Automatisch koppelen moet dan gokken welke, en een verkeerde gok maakt van twee mensen stilletjes één. Dat krijg je er niet meer uit.

Daarom vragen we het aan de enige die het antwoord weet. Wie is aangemeld, ziet bovenaan zijn overzicht staan: "X heeft een profiel voor je aangemaakt op jouw e-mailadres, als vriend. Ben jij dat?" Met twee knoppen, en dat is alles.

Antwoord	Wat er gebeurt
Ja, dat ben ik	Dezelfde samenvoeging als bij een uitnodiging die je ingelogd aanneemt.
Nee, dat ben ik niet	Er verandert niets, en de vraag komt niet terug (persons.link_declined_by_user_id, db/17).
Niets	Er verandert niets. De vraag blijft staan tot hij hem beantwoordt.

Waarom dat mag zonder dat het lekt: wie deze vraag krijgt, heeft zojuist met een code in dat postvak bewezen dat het adres van hem is. De enige die iets te zien krijgt is dus de eigenaar van het adres - en over zichzelf. Hij ziet de naam van degene die de aantekening bijhoudt en wat hij van hem zou zijn; dat is precies genoeg om de vraag te kunnen beantwoorden, en niet meer.

Andersom gebeurt er niets: degene die de aantekening maakte krijgt geen melding dat er iets is gevraagd, en geen melding dat het antwoord nee was. Anders zou het weigeren zélf een mededeling worden over wie er wel of niet een account heeft.

De vraag staat op het overzicht en niet als popup bij het aanmelden. Iemand kan je ook toevoegen nádat jij je al had aangemeld, en een popup die je wegklikt is een vraag die je nooit meer krijgt.

Er is hierdoor geen apart goedkeuringsverzoek nodig voor het toevoegen van iemand die al een account heeft. Dat stond eerst in het plan, maar het lost zichzelf op: wie nooit andermans profiel adopteert, geeft ook niets weg. Wil je die persoon er echt bij, dan nodig je uit — en die uitnodiging is de toestemming.

Wat er verhuist bij het samenvoegen

Zie SamenvoegService. Een niet-geclaimd profiel bezit weinig, want kluisitems horen bij de persoon áchter een account. Wat er wel aan hangt:

• lidmaatschappen — staat het doel al in die familie, dan verdwijnt het dubbele lidmaatschap; de relatie die er al stond blijft leidend, want die is ingevuld door de eigenaar van die familie
• berichten die voor het duplicaat klaarstonden of ervandaan kwamen
• foto's waar de persoon op staat; hoogstens één blijft profielfoto
• uitnodigingen, ook de gebruikte
• rollen in een nalatenschap — een dubbele aanwijzing of een tweede overlijdensmelding van dezelfde gebruiker verdwijnt, anders vervalst dat het aantal
• lege velden worden aangevuld vanuit het duplicaat, nooit overschreven: wat bij het doel staat komt van de persoon zelf en weegt zwaarder

Het duplicaat wordt niet verwijderd. Hij blijft staan met merged_into_person_id naar waar hij in is opgegaan — er hangt geschiedenis aan, en een verwijderde rij is niet terug te halen.

Twee grenzen, allebei met een controle erop:

• Je kunt alleen samenvoegen met je eigen profiel.
• Twee geclaimde profielen gaan nooit automatisch samen. Dat zijn twee echte accounts met ieder een eigen kluis; daar hoort een mens naar te kijken.

De profielfoto

Hier lag een echte afweging. Zet Ysabeau zelf een foto, dan is die versleuteld met háár sleutel. Haar vader zou hem dan niet kunnen zien — precies het tegenovergestelde van de bedoeling.

Gekozen: de kleine versie is niet versleuteld, de foto op ware grootte wel.

De redenering: een profielfoto is juist het ding dat je aan andere mensen laat zien. Hem behandelen als kluismateriaal is niet eerlijk over wat het is, en zou betekenen dat je voor elke kijker een sleutel moet uitdelen en weer intrekken zodra families veranderen.

De prijs is echt en bewust genomen: wie toegang heeft tot de database, ziet gezichten van 160 pixels. Alles waar het in MijnBesluit om gaat — wachtwoorden, polissen, uitvaartwensen, berichten — blijft versleuteld, net als de foto op ware grootte.

Wie hem mag zien: iedereen met wie je in een familie zit. Dat is de kring die mensen zelf samenstellen door elkaar toe te voegen en uit te nodigen. Die controle staat in VaultService en niet in de schermen: een toegangsregel hoort niet af te hangen van de vraag of elk scherm eraan denkt.

Kleine versies uit de allereerste opzet waren nog wél versleuteld. Die worden bij het eerste gebruik automatisch vervangen; daar is geen migratie voor nodig.

Waar hij staat: overal waar een mens in een lijst staat — Mijn mensen, je beheerders, de nalatenschappen die aan jou zijn toevertrouwd — en in app en website hetzelfde. Dat zit in één onderdeel, Penning.razor. Dat bestand staat twee keer op schijf (de app en de site delen geen project) en een zelfcontrole vergelijkt ze letterlijk, zodat ze niet uit elkaar lopen.

Jezelf sta je niet tussen je eigen mensen — je bent geen familielid van jezelf. Bovenaan Mijn mensen staat daarom een eigen kaart die naar Mijn profiel gaat. Daar wijzig je je naam, je geboortedatum, je foto en je e-mailadres; dat laatste met een code naar het nieuwe adres. Zonder die kaart gingen mensen hun eigen gegevens zoeken in de lijst waar ze juist niet in staan.

Het adres van een persoon is niet uniek

Dat lijkt een detail van de database, maar het is de hele regel hierboven in één index.

Op persons.email stond een UNIQUE-index. Het gevolg: voegde je iemand toe met een adres dat al ergens in de database stond - bij wie dan ook, ook bij een wildvreemde - dan liep het opslaan stuk. Voor de gebruiker was dat een knop die niets deed. Wie een adres het eerst invulde, bepaalde daarmee dat niemand anders die persoon nog kon toevoegen. In een applicatie waar twee ouders allebei hun dochter toevoegen is dat precies de verkeerde kant om.

Sinds db/15_adres_niet_uniek.sql is het een gewone index. Wat dat betekent voor de code:

• Zoeken op adres kan meer dan één profiel opleveren. ListByEmailAsync geeft ze allemaal; FindByEmailAsync geeft er één, geclaimde eerst, zodat je in elk geval altijd dezelfde terugkrijgt.
• Wie zijn eigen profiel zoekt, moet daarop filteren en niet op de eerste treffer. Met de eerste de beste kreeg je die van een ander te pakken, viel de eigendomscontrole uit, en maakte je een tweede aantekening aan voor iemand die je zelf al had staan.
• Bij het wijzigen is alleen een botsing met je eigen profiel een bezwaar. Dat een ander dezelfde persoon kent, is geen fout maar het uitgangspunt.
• Een account maken koppelt niet meer op adres. Wie zonder uitnodiging een account maakt, krijgt zijn eigen profiel; de aantekening van een ander komt bij hem terecht op het moment dat hij díens uitnodiging aanneemt. Zoeken op adres betekende andermans aantekening adopteren zonder dat die ander er iets over te zeggen had, en met meerdere aantekeningen was het bovendien de vraag welke je dan kreeg.

Bij users.email blijft uniek juist wél gelden: dat is een account, en er kan er maar één per adres zijn. Een zelfcontrole bewaakt allebei die kanten.

Wat hier nog niet is opgelost

• Mensen zonder e-mailadres kunnen nooit claimen, dus hun duplicaten blijven bestaan. Voor een kluis en berichten maakt dat niet uit. Zodra er ooit een gedeelde stamboom komt, wordt het wel een vraag.
• Samenvoegingen van vóór 15 september 2026 zijn niet terug te draaien. Daar is geen bonnetje van (zie hieronder); de gegevens om het mee te doen bestaan eenvoudigweg niet. Dat is geen fout die nog te repareren valt.

Samenvoegen terugdraaien

Samenvoegen was lange tijd onomkeerbaar, en dat stond hier ook als open punt. Dat is het nu niet meer.

Waarom het niet zomaar kon: ná een samenvoeging is niet meer te zien wélke lidmaatschappen, berichten en bestanden bij het duplicaat hoorden. Ze staan gewoon bij het doel, tussen alles wat daar al stond. Een gok daarop zou andermans gegevens meesleuren.

Daarom schrijft elke samenvoeging nu een bonnetje. In de tabel samenvoegingen komt per samenvoeging één regel te staan met precies wat er is verhuisd, als lijstje stappen in JSON. Terugdraaien is die lijst in omgekeerde volgorde aflopen. Regels die bij het samenvoegen zijn weggegooid — een dubbel lidmaatschap, een dubbele beheerder — staan er als volledige kopie in, want die moeten opnieuw worden aangemaakt.

Drie dingen die daarbij met opzet zo zijn:

• Wat er ná de samenvoeging is bijgekomen, blijft staan. Wat Ysabeau daarna zelf in haar kluis heeft gelegd, is van haar en hoort bij haar. Alleen wat in het bonnetje staat gaat terug.
• Een veld dat we hebben aangevuld gaat alleen leeg als het nog steeds is wat wij invulden. Heeft de persoon het daarna zelf aangepast, dan is het van hem en blijft het staan.
• Terugdraaien mag alleen een beheerder. Samenvoegen doet de persoon zelf — alleen hij mag zeggen dat twee profielen hem zijn — maar het raakt ook de gegevens van degene die het duplicaat ooit aanmaakte. Gaat het mis, dan hoort er een mens naar te kijken.

Is het doelprofiel zelf later ergens in opgegaan, dan weigert het terugdraaien: het bonnetje wijst dan niet meer naar waar de gegevens staan. Die latere samenvoeging gaat eerst terug.

Het bonnetje blijft na afloop staan, met wanneer en waarom het is teruggedraaid. Dát er ooit is samengevoegd, is zelf ook geschiedenis.

De beheerder

Er is één beheerpagina, /beheer, en die is met opzet bijna leeg. Hij bestaat voor de twee situaties waar niemand anders uit komt: een overlijden dat ten onrechte is bevestigd terwijl de bezwaarlink verlopen is — het account staat dan op "overleden", inloggen kan niet meer, en er is geen weg terug — en een samenvoeging die niet had gemoeten.

Wat een beheerder wél kan:

• een profiel opzoeken op het volledige e-mailadres
• een bevestigd overlijden terugdraaien, met een verplichte reden die in het logboek komt
• een samenvoeging terugdraaien, ook met een verplichte reden

Beide handelingen hebben iets gemeen dat ze veilig maakt: ze geven nooit toegang. De ene neemt toegang weg, de andere zet terug wat er stond.

Wat hij niet kan, en ook nooit moet kunnen:

• een kluis openen. Zijn enige handeling neemt toegang wég en geeft hem nooit. Wie dat verandert, haalt de bodem onder het hele product vandaan.
• op naam zoeken. Dat zou de zoekmachine op mensen zijn die hierboven wordt afgewezen. Je moet al weten wie je zoekt, omdat diegene contact met je heeft opgenomen.
• iemand beheerder maken. Dat gaat met de hand in de database: UPDATE users SET is_beheerder = 1 WHERE email = '...'. Wat niet via de applicatie kan, kan ook niet via een lek in de applicatie.

Wie geen beheerder is, krijgt op die pagina "Niet gevonden" te zien — niet "geen toegang". Een pagina waarvan je niet weet dat hij bestaat, ga je ook niet proberen.

Het menu-item Beheer

In het menu staat Beheer alleen voor een beheerder. Of dat zo is, komt uit het inlogcookie (de claim mijnbesluit:beheer) en niet uit de database.

Dat is niet uit zuinigheid. Het menu zit in de layout, en die staat op élke pagina; hij wordt tegelijk met de pagina zelf opgebouwd. Vroeg de layout het op bij de database, dan liep die vraag gelijk op met de vraag van de pagina — over dezelfde DbContext, en die kan er maar één tegelijk aan. Het gevolg was A second operation was started on this context instance: een foutpagina die er soms wel en soms niet was, afhankelijk van welke vraag net eerder klaar was. Een layout hoort niets op te halen; de zelfcontrole "Een layout haalt zelf niets op" houdt dat vast.

De prijs is dat iemand die net beheerder is gemaakt het menu-item pas ziet na opnieuw inloggen. Dat is te overzien, want de claim is geen sleutel maar een lampje: /beheer en /beheer/adverteren kijken zelf nog in de database of je het écht bent, en doen dat bij elke handeling opnieuw. Wordt iemands beheerderschap ingetrokken, dan is hij dus meteen geweerd — alleen blijft het menu-item nog staan tot hij uitlogt.