GEWIJZIGD 09-08-2026 00:18IN-APP + INFRAHOOGSTE PRIORITEIT · PRE-LAUNCH-GATE
D11 · Sleutelcustody & escrow
⚠ Waarom is dit een alarm?
- R4M's kernbelofte is: "je identiteit ligt in een verzegelde kluis — wij kunnen er zelf niet in, alleen onder wettig bevel kan hij open."
- Maar vandaag hebben wij de twee operationele sleutels zélf in handen: de afleidingssleutel én de sleutel op het verzegelde identiteitsbewijs (het volledige model kent drie sleutels — zie 🔑 Sleutels). Technisch kunnen wij dus wél zelf iedereen ontmaskeren — de belofte "wij kunnen niet terug" is nu niet waar.
- Daarom: niet lanceren vóór dit opgelost is (sleutels scheiden, bv. één sleutel bij een externe partij in escrow). Anders verkopen we een kluis waarvan we zelf de reservesleutel in onze zak hebben — juridisch en commercieel dodelijk als dat uitkomt.
PRE-LAUNCH-GATE = een poort die dicht blijft tot D11 gebouwd is. Hieronder staat wat er precies moet gebeuren.
Vandaag liggen de afleidingssleutel en de sleutel op het verzegelde identiteitsbewijs bij dezelfde partij: ons. Daardoor is offline elke gebruikers-id tegen ons eigen register door te rekenen, en is “wij kunnen zelf niet terug” niet waar. Vier stappen:
- Splits de opslag — het register bevat enkel person_code, uitbetaaladres en status; identiteitsbewijzen in een aparte verzegelde blob die in normale werking nooit opengaat.
- Afleidingssleutel in een HSM, niet-exporteerbaar. person_code = HMAC-SHA256(K_uniq, issuer_id ‖ subject_id), berekend binnen de HSM, met logging en rate limit op elke aanroep.
- Sleutel op het verzegelde bewijs in escrow: 2-van-3, verdeeld over R4M, ARTES en een auditor of notaris.
- Sterkere variant indien haalbaar: versleutel de blob meteen naar de publieke sleutel van de bewaargever, zodat wij nooit een private sleutel bezitten.
- De derde sleutel: de handtekeningsleutel van de uitgever (SD-JWT/VC issuer-key, zie D1 en D8) — zelfde regime als sleutel 1: niet-exporteerbaar, ondertekening gebeurt binnen de hardware, met een rotatie- en intrekkingsplan. Moet geregeld zijn vóór de eerste externe attestatie. Wie deze sleutel steelt kan attestaties vervalsen, en voor een klant is dat erger dan re-identificatie: bij re-identificatie lekt een identiteit, bij een valse attestatie vertrouwt hij een mens die niet bestaat.
⚠ Wat D11 wél en niet oplost — de claim splitst per sleutel
Sleutel 2 (escrow 2-van-3): "openen kan structureel niet zonder een tweede partij" is na D11 letterlijk waar. Die zin mag je zo verkopen.
Sleutel 1 (afleidingssleutel in KMS/HSM): wint iets anders. De sleutel kan niet meer gestolen of gekopieerd worden en elk doorrekenen is gelogd en gelimiteerd, dus massaal of stiekem re-identificeren kan niet meer onopgemerkt. Maar wie onze KMS-toegang heeft kan één kandidaat-identiteit gericht doorrekenen en tegen het register leggen. Dat blijft toegangscontrole, geen structurele onmogelijkheid. Zeg het ook zo — zie 🔑 Sleutels 4a en Deel A.
Waarom hoogste prioriteit: Zet 3, functionaliteitsvoorbeeld 8 en de volledige kluis-metafoor hangen hieraan. Zonder D11 verkopen wij een belofte.
Let ook op: issuer_id hoort in de afleiding, anders botsen twee identiteitsbronnen ooit op elkaar.
Verificatie, huidige toestand & bouwplan (09-08-2026)
Code-verificatie (live, tag v0.28.25 = commit 860a6a6): geen SHA-1/MD5, alles SHA-256. identity.ts:26 = sha256(provider:subject:salt) — een gesalte hash, geen echte HMAC-constructie. Geen lek zolang de salt geheim blijft, maar een KMS rekent uitsluitend HMAC: de overstap verandert álle person_codes. Migratie moet daarom vóór de eerste échte registraties gebeuren — dit is een PRE-LAUNCH-GATE, niet “na de demo”.
Huidige toestand: géén KMS. IDENTITY_SALT is een gewone omgevingsvariabele op Fly; de berekening gebeurt in de eigen app. Providerkeuze (AWS KMS EU-regio vs. Europees alternatief) wacht op advocaat Nele.
Bouwplan stap 1 (nu, provider-onafhankelijk): één identity-adapter-module voor alle pseudoniem-afleiding, met twee backends — (a) de huidige sha256, default, byte-identiek aan vandaag, bewezen met een regressietest; (b) een lege KMS-HMAC-interface, fail-closed, zonder provider hard te coderen. Plus migratielogica. Geen deploy zonder review.
IN-APP MODULEeerst APART prototypen
D1 · x401-issuer-module
Simpel gezegd: x401 is geen nieuwe app maar een taal. Wij leren onze bestaande app die taal spreken, zodat elke dienst die x401 gebruikt onze bewijzen kan afnemen — één nieuwe voordeur, dezelfde motor erachter.
Antwoord op de kernvraag: x401 is GEEN nieuwe app en geen add-on van iemand anders — het is een taal. Wij bouwen een module in de bestaande app die x401-challenges beantwoordt met een R4M-attestatie (Verifiable Credential / SD-JWT, via OID4VC-standaarden). Eén nieuwe voordeur op de bestaande identiteitslaag; de rail eronder blijft dezelfde. Elke dienst die x401 spreekt wordt daarmee een potentiële afnemer van R4M-bewijzen — dat zijn de “nieuwe openingen”, zonder nieuwe app.
Prototype apart (r4m-x401-proto), tegen de open spec testen, dan pas als module inbrengen.
Uitleg & opmerkingen
Waarom bijbouwen: elke dienst die x401 spreekt wordt hiermee een potentiële afnemer van R4M-bewijzen — nieuwe openingen, zonder nieuwe app. De rail eronder blijft dezelfde.
Bijvoorbeeld: een boekingssite eist een x401-bewijs van agents. Jouw agent toont de R4M-attestatie “one verified unique EU human, accountable” en mag binnen — die site is vanaf dat moment afnemer van R4M-bewijzen.
IN-APP MODULEontwerp eerst
D2 · Mandaten & delegatie
Simpel gezegd: Je geeft je robot een boodschappenlijstje mét limiet: max €50, alleen deze week, alleen die winkel. Zwart op wit, intrekbaar. Zonder dit blok is “agent namens mens” juridisch gatenkaas; mét dit blok heb je het bewijsstuk dat de markt (Visa TAP, Mastercard Agent Pay, AP2) vraagt. Let op: de AI-wet eist dit níét — art. 50 verplicht alleen te melden dát er een machine praat, niet namens wie (correctie 14-08, zie Archief).
De mens autoriseert zijn agent beperkt: welke agent, welk bedrag-plafond, welk tijdvenster, welke actiecategorie — cryptografisch getekend, intrekbaar. Zonder dit blok is “agent namens mens” juridisch en praktisch gatenkaas; mét dit blok sluit R4M aan op waar Visa TAP/Mastercard/AP2 naartoe bewegen.
Simpel gezegd: “Je geeft je robot een boodschappenlijstje mét limiet: max €50, alleen deze week, alleen bij die winkel. Zwart op wit, intrekbaar.”
Uitleg & opmerkingen
Waarom bijbouwen: zonder dit blok is “agent namens mens” juridisch en praktisch gatenkaas; mét dit blok sluit R4M aan op waar Visa TAP, Mastercard en AP2 naartoe bewegen.
Bijvoorbeeld: je agent probeert €80 uit te geven terwijl zijn mandaat op €50 staat — de transactie wordt geweigerd en jij ziet de poging in het log. Trek je het mandaat in, dan stopt de agent per direct.
IN-APP MODULE
D3 · Levenscyclus van het bewijs
Simpel gezegd: Wat als iemand overlijdt, zijn eID kwijtraakt of een sleutel gestolen wordt? Dan moet een bewijs intrekbaar, vernieuwbaar of bevriesbaar zijn. Dit vergeten is dé klassieke fout van identiteitssystemen.
Wat als iemand overlijdt, zijn eID kwijt is, of een sleutel gecompromitteerd raakt? Nodig: intrekking (revocation), her-verificatie-cadans, en een “bevroren”-status. Dit vergeten is de klassieke fout van identiteitssystemen.
Uitleg & opmerkingen
Waarom bijbouwen: een identiteitsbewijs zonder levenscyclus wordt vanzelf onbetrouwbaar — dit blok houdt elk bewijs controleerbaar geldig, ook bij verlies, diefstal of overlijden.
Bijvoorbeeld: iemand verliest zijn eID. Zijn R4M-status gaat op “bevroren”, eerder afgegeven bewijzen worden ingetrokken, en na her-verificatie met een nieuwe eID gaat alles weer open — zonder dat er ooit een vals bewijs in omloop was.
IN-APP MODULEstond al op de roadmap
D4 · Recovery & payout-adresbeveiliging
Simpel gezegd: Dieven kraken niet de kluis — ze proberen het rekeningnummer te wijzigen waarnaar wij uitbetalen. Daarom: meerdere adressen per persoon, een zware controle bij elke wissel, en een herstelpad als je toegang kwijt bent.
Meerdere payout-adressen per persoon, sterk geauthenticeerde adreswissels, herstelpad bij verlies. Dit is waar dieven zullen aanvallen — adreswissel = de nieuwe “phishing”.
Uitleg & opmerkingen
Waarom bijbouwen: wie uitbetaalt, wordt aangevallen op het uitbetaaladres — dit blok is de verdediging op het punt waar de schade het grootst zou zijn.
Bijvoorbeeld: een dief probeert jouw payout-adres te wijzigen naar zijn eigen rekening. De wissel eist sterke her-authenticatie, er geldt een wachttijd, en jij krijgt direct bericht — één klik en de wissel is geblokkeerd.
IN-APP MODULEjuridisch afstemmen (advocaat)
D5 · Sanctiescreening & Travel Rule op payouts
Simpel gezegd: Wie geld uitkeert, moet checken dat de ontvanger niet op een sanctielijst staat en soms info met de betaling meesturen. Onvermijdelijk voor het burgeruitkering-verhaal — beter nu ingetekend dan achteraf ingebroken.
Wie uitbetaalt aan mensen, moet kunnen screenen tegen sanctielijsten en (boven drempels) herkomst/bestemming-info meegeven. Onvermijdelijk voor het burgeruitkering-verticaal; beter nu ingetekend dan achteraf ingebroken.
Uitleg & opmerkingen
Waarom bijbouwen: zonder screening mag geen overheid of NGO met ons uitkeren — dit blok is een toegangsvoorwaarde voor de eerste markt (Zet 4), en de exacte invulling ligt bij de advocaat (vragen 34–37).
Bijvoorbeeld: een payout matcht op een naam van de EU-sanctielijst. De uitbetaling moet dan automatisch bevriezen en gemeld worden in plaats van doorlopen — en bij een false positive is er een net review-pad.
INFRA-BESLISSING
D6 · EU-dataresidentie & verwerkersovereenkomsten
Simpel gezegd: Overheden en banken eisen dat data in de EU blijft én dat het op papier staat. Dit is geen code maar een infrakeuze: de serverregio vastpinnen en documenteren.
Overheids- en bankklanten eisen EU-hosting en een verwerkersovereenkomst. Check/pin de Fly-regio op EU; documenteer het.
Uitleg & opmerkingen
Waarom bijbouwen: zonder aantoonbare EU-dataresidentie valt R4M bij elke overheids- of bankaanbesteding in de eerste ronde af — dit is een infra-beslissing die verkoop mogelijk maakt.
Bijvoorbeeld: een aanbesteding vraagt “waar staat de data, en is er een verwerkersovereenkomst?” Het antwoord moet dan zwart-op-wit zijn: Fly-regio vastgepind op EU, gedocumenteerd, DPA getekend (vragen 38–40).
GEWIJZIGD 02-08-2026 23:24APART BOUWENPRIORITEIT OMHOOG — dit is nu ook ons CRA-meldpad
D7 · Vertrouwensoppervlak
Simpel gezegd: Een publieke statuspagina, een meldpunt voor beveiligingslekken en een changelog. Kost bijna niets, maar zonder oogt een vertrouwensproduct amateuristisch — mét oogt het volwassen.
Publieke status-pagina, security.txt, responsible-disclosure-beleid, changelog. Een vertrouwensproduct zonder deze drie oogt amateuristisch; mét oogt het volwassen. Sinds de CRA-meldplicht (11 sept 2026) is security.txt met een responsible-disclosure-adres geen cosmetica meer: het is het kanaal waarlangs kwetsbaarheden binnenkomen die wij binnen 24 uur moeten kunnen beoordelen.
Uitleg & opmerkingen
Waarom bijbouwen: R4M verkoopt vertrouwen — dan moet het vertrouwensoppervlak zelf ook zichtbaar op orde zijn. Goedkoopste blok met het snelste effect (“kan deze week”).
Bijvoorbeeld: een security-onderzoeker vindt iets. Via security.txt vindt hij direct het disclosure-beleid, meldt het netjes, en de fix verschijnt in de publieke changelog — vertrouwen dat je kunt aanwijzen.
ROUTINEAPART testrepo
D8 · Conformance & interop
Simpel gezegd: De open standaarden hebben officiële testen. Wij moeten aantoonbaar slagen op die testen, zodat “wij zijn conform” geen bewering is maar een bewijs.
De x401/OID4VP/SD-JWT-specs hebben testvectoren; R4M-attestaties moeten daar aantoonbaar tegen slagen. “Wij zijn conform” met bewijs is je verdediging in het complexe wereldje.
Uitleg & opmerkingen
Waarom bijbouwen: in een wereld van open standaarden win je niet met “vertrouw ons” maar met aantoonbare conformiteit — dit blok maakt van Zet 2 (EU-issuer in de x401-stack) een controleerbaar feit.
Bijvoorbeeld: in een integratiegesprek met een Circle-klasse partij vraagt hun techteam om interop-bewijs. Het antwoord is een testrepo waarin R4M-attestaties zichtbaar tegen de officiële x401/OID4VP/SD-JWT-testvectoren slagen.
CONTENTgeen code
D9 · Verdienmodel-blok
Simpel gezegd: Eerlijk opschrijven hoe R4M geld verdient terwijl burgeruitkeringen 0% blijven: de burger betaalt nooit; de systemen die ons bewijs en onze rail gebruiken wél.
Eerlijk uitschrijven hoe R4M geld verdient terwijl burgeruitkeringen 0% blijven: x402-toegangsfees, issuer-/attestatie-fees, licenties op de Lawful Access Module, integratie-/pilotcontracten.
Simpel gezegd: “De burger betaalt nooit; de systemen die ons bewijs en onze rail gebruiken wél.”
Uitleg & opmerkingen
Waarom bijbouwen: zonder eerlijk uitgeschreven verdienmodel blijft “0% op burgeruitkeringen” een belofte die vragen oproept — dit blok maakt hem geloofwaardig en verkoopbaar (en fee-kwalificatie is vraag 41 voor de advocaat).
Bijvoorbeeld: een NGO betaalt een pilotcontract en integratie-fee; de 100 gezinnen ontvangen exact 100 × €50, met 0% ingehouden — en iedereen kan in het kasboek zien dat beide waar zijn.
VISIE-BLOKgeen actie nu
D10 · Horizon: gekwalificeerde status
Simpel gezegd: eIDAS kent een officieel EU-keurmerk voor vertrouwensdiensten (QTSP). Dat is het eindspel voor een EU-issuer — stip op de horizon, pas concreet na juridisch advies.
eIDAS kent “gekwalificeerde vertrouwensdiensten” (QTSP). Dat is het institutionele eindspel voor een EU-issuer. Benoemen als stip op de horizon; pas na juridisch advies concretiseren.
Uitleg & opmerkingen
Waarom benoemen: het toont dat de EU-issuer-route (Zet 2) een institutioneel eindspel heeft — richting zonder verplichting; concretiseren pas na juridisch advies (vraag 43).
Bijvoorbeeld: met QTSP-status zou R4M op de officiële EU-vertrouwenslijst staan, naast gekwalificeerde handtekening-diensten — het soort stempel waarmee overheidsdeuren vanzelf opengaan.
NIEUW 02-08-2026 23:24IN-APP MODULEjuridisch afstemmen
D12 · Rechthebbenden-matching
Simpel gezegd: De gemeente heeft de lijst van wie recht heeft; wij bewijzen wie écht en uniek is. We vergelijken versleuteld: wij zien geen namen, zij zien geen accounts, en zonder match geen uitkering. Wie recht heeft, bepaalt altijd de overheid — nooit wij.
Bij een overheidsuitkering levert de gemeente de lijst van rechthebbenden. Wij vergelijken versleuteld: wij zien geen namen, zij zien geen R4M-account. Geen match = geen uitkering. Dit staat al beschreven in functionaliteitsvoorbeeld 1 maar bestaat nog niet als bouwblok, terwijl heel Zet 4 eraan hangt. Raakt het rijksregisternummer — vraag 56 aan de advocaat.
De grens die wij niet overschrijden: wij bepalen nooit wie recht heeft. Dat blijft de overheid.
NIEUW 02-08-2026 23:24IN-APP MODULE
D13 · Assisted verification
Simpel gezegd: Niet iedereen heeft een smartphone of eID-vaardigheid. Een hulpverlener verifieert dan samen met de burger op zijn eigen toestel — zelfde bewijs, zelfde kasboek, alleen begeleid. Zonder dit is geen enkele overheidspilot haalbaar.
Verificatie door een hulpverlener op zijn eigen toestel, samen met de burger, voor wie geen eID, geen smartphone of geen digitale vaardigheid heeft. Zelfde bewijs, zelfde kasboek, alleen begeleid. Zonder dit blok is geen enkele overheidspilot haalbaar: digitale uitsluiting is politiek onaanvaardbaar en het is de eerste vraag die een gemeenteraad stelt.