← vitrine

Quickstart: is dit een uniek mens?

Eén API-aanroep, geen account, geen sleutel, geen kosten om te controleren. Je krijgt een ja of een nee — en nooit iemands naam.

Wat je koppelt

Een R4M-attestatie is één ondertekende zin: "op tijdstip T is een uniek mens geverifieerd door <provider> op zekerheidsniveau <assurance>". Meer staat er niet in, en meer krijg je dus ook nooit terug.

Verificatie zelf is gratis en open: een bewijs dat alleen wij kunnen controleren, is geen bewijs.

In drie stappen

Stuur je gebruiker naar de eID-stap

Eén link. Zet je eigen naam in voor= — die bepaalt de code die jij terugkrijgt.

https://r4m-franky.fly.dev/demo/pas.html?voor=jouw-naam

Hij komt terug op die pagina met een attestatie-id in de vorm att_…, dat hij aan jou doorgeeft. Nog niet gebouwd: automatisch terugsturen naar een URL van jou. Dat vraagt een geregistreerde return-URL per klant — een open doorverwijzing zetten we niet op een publiek endpoint. Vraag ernaar zodra je koppelt.

Controleer het id — dit is de hele integratie

curl -s https://r4m-franky.fly.dev/api/public/attest/<attestatie-id>

Probeer het nu, zonder gebruiker. Er staat één vast voorbeeld klaar dat altijd geldig is. Plak deze regel en je krijgt precies het antwoord hieronder — letterlijk, elke dag:

curl -s https://r4m-franky.fly.dev/api/public/attest/att_demo000quickstart

{
  "valid": true,
  "attestationId": "att_demo000quickstart",
  "claim": "sample-not-a-person",
  "provider": "demo",
  "environment": "demo",
  "assurance": "none",
  "audience": "quickstart",
  "uniquenessRef": "dfc7e63ba3ddb88c27ff179b576a69ba",
  "issuedAt": "2026-08-14 00:00:00Z",
  "expiresAt": "2099-12-31 23:59:59Z",
  "sample": true,
  "note": "Dit is het vaste voorbeeld uit de quickstart — geen persoon, geen verificatie…",
  "token": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCIsImtpZCI6…"
}

Dat voorbeeld is bewust geen mens: het draagt provider: "demo", claim: "sample-not-a-person" en sample: true, het verloopt nooit, en het telt niet mee in onze publieke cijfers. Zo kun je je integratie afmaken vóór er ooit iemand door de eID-stap ging.

Een echte attestatie ziet er hetzelfde uit, met drie velden anders — "claim": "unique-human", "provider": "itsme", "environment": "sandbox" (later "production") — plus "assurance": "high", jouw audience, en een expiresAt 15 minuten na uitgifte. Geen sample, geen token: dat token hoort de houder toe.

Vertak op één veld

Alleen op valid. Onbekend, verlopen en ingetrokken geven allemaal HTTP 200 met valid: false en een leesbare reason — nooit een statuscode waar een foutafhandeling per ongeluk "geverifieerd" van maakt.

{ "valid": false, "reason": "verlopen op 2026-08-14 00:56:07Z — vraag de persoon een nieuwe verificatie" }

Wat je met `uniquenessRef` doet

Dat is jouw vaste code voor deze mens. Bewaar hem naast het account, en je hebt "één mens, één plaats" afgedwongen: dezelfde persoon die morgen een tweede account maakt, komt terug met exact dezelfde code.

Bij een andere afnemer krijgt diezelfde persoon een andere code. Twee klanten kunnen hun bestanden dus nooit aan elkaar koppelen — de code is per afnemer afgeleid, niet universeel.

Wat je krijgt	Wat je nooit krijgt
uniek mens, ja of nee	naam
vaste code per afnemer	rijksregisternummer
provider + zekerheidsniveau	geboortedatum
tijdstip en geldigheid	e-mailadres of adres

Het door de identiteitsprovider ondertekende bewijs bewaren wij verzegeld achter een aparte sleutel — alleen te openen bij audit of gerechtelijk bevel, nooit door een API-aanroep.

Zonder ons te geloven (offline controle)

Elke attestatie is óók een ondertekende token (JWS, Ed25519). Haal de publieke sleutel één keer op en controleer de handtekening zelf, in je eigen proces:

curl -s https://r4m-franky.fly.dev/api/public/attest/jwks.json

{ "keys": [ { "kty": "OKP", "crv": "Ed25519", "x": "…", "kid": "…", "alg": "EdDSA", "use": "sig" } ] }

Of laat ons een aangeboden token narekenen — handtekening eerst, daarna intrekking en geldigheid. Het voorbeeld-token haal je uit het token-veld van stap 2, dus ook dit is nu te proberen zonder gebruiker:

TOKEN=$(curl -s https://r4m-franky.fly.dev/api/public/attest/att_demo000quickstart | sed -n 's/.*"token":"\([^"]*\)".*/\1/p')
curl -s -X POST https://r4m-franky.fly.dev/api/public/attest/verify \
  -H 'content-type: application/json' \
  -d "{\"token\":\"$TOKEN\"}"

Antwoord: hetzelfde blok als in stap 2. Verander één letter in het token en het wordt valid: false met een reden over de handtekening.

Een gemanipuleerd token faalt op cryptografie, vóór er iets opgezocht wordt. Een geldig ondertekend maar ingetrokken token faalt alsnog — de handtekening is nooit het laatste woord voor wie online kan controleren.

Eerlijk over de stand van zaken. Deze koppeling draait vandaag tegen de testomgeving van de identiteitsprovider. Dat staat letterlijk in elke attestatie ("environment": "sandbox"), zodat een testbewijs zich nooit als een echt bewijs kan voordoen. Bij de overstap naar productie verandert dat veld — en niets anders aan jouw integratie.

Alle endpoints

Aanroep	Wat het doet
`GET /api/public/attest`	Wat dit is, live cijfers en deze quickstart, machine-leesbaar
`GET /api/public/attest/:id`	Geldt deze attestatie nu? — de enige aanroep die de meeste klanten ooit doen
`POST /api/public/attest/verify`	Iemand overhandigt een token; is het echt en nog geldig?
`GET /api/public/attest/jwks.json`	De publieke sleutel — voor eeuwige offline controle
`GET /api/public/ledger`	Het publieke kasboek: elke verificatie laat er een regel achter
`GET /api/public/reconciliation`	Bewijs dat het geld sluit, natelbaar uit de opgeslagen data alleen

Alles hierboven is publiek, alleen-lezen en zonder sleutel bereikbaar. CORS staat open, dus een browser kan het rechtstreeks — geen proxy nodig.

Zelf uitproberen: doorloop de flow als gebruiker → · de hele vitrine · deze pagina als JSON