JSON-LD uitgelegd
JSON-LD is gewone JSON met één extra regel die zegt wat de velden betekenen. Die regel maakt van een lokale veldnaam een wereldwijd gedefinieerde, zodat een systeem dat uw gegevens nooit eerder heeft gezien toch kan uitzoeken waar u het over hebt. Het is sinds 2014 een W3C-standaard, het is hoe zoekmachines deze pagina lezen, en het is waarop het W3C-datamodel voor verifieerbare credentials is gebouwd.
Het probleem met gewone JSON
JSON zegt hoe gegevens worden opgeschreven. Het zegt niets over wat het allemaal betekent. Een veld dat name heet kan een persoon, een bedrijf of een product zijn. Een veld dat id heet kan een klantnummer, een paspoortnummer of een rij in iemands database zijn. Twee systemen kunnen allebei volmaakt geldige JSON opleveren en het toch over elk veld oneens zijn.
In de praktijk wordt dat gat gedicht met een afspraak. De twee partijen leggen vast wat de velden betekenen en bouwen hun software daarop. Dat werkt voor één koppeling, wordt duur bij tien, en werkt helemaal niet meer wanneer een credential dat in het ene land is uitgegeven begrepen moet worden door een verifier in een ander land die vooraf met niemand heeft gesproken.
Wat de @context doet
JSON-LD dicht dat gat in het document zelf. Een @context koppelt elke korte veldnaam aan een wereldwijd unieke identificatie, normaal gesproken een URL die beheerd wordt door degene die het vocabulaire heeft gedefinieerd. Het veld blijft kort en leesbaar voor een mens en wordt ondubbelzinnig voor een machine.
Gewone JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Geldig, leesbaar en betekenisloos voor iedereen die niet vooraf te horen heeft gekregen wat de velden horen te bevatten.
Dezelfde gegevens als JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Elk veld verwijst nu naar een gepubliceerde definitie, zodat een systeem dat dit document nooit eerder heeft gezien het toch correct kan lezen.
- @context benoemt het vocabulaire waarin elk veld in het document is gedefinieerd.
- @type zegt wat voor soort ding het document beschrijft, zodat de juiste definities uit dat vocabulaire worden gekozen.
Aan de gegevens zelf verandert niets. Dezelfde waarden in dezelfde vorm dragen nu een verwijzing naar de definitie van elk veld. Een ontvangend systeem dat het vocabulaire herkent weet precies wat het heeft gekregen, en een systeem dat dat niet doet kan het document nog steeds als gewone JSON lezen en de rest negeren.
Dat is het hele idee. Betekenis reist mee met het document in plaats van in een specificatie te zitten waarover de twee partijen het vooraf eens moesten worden.
Waar het opduikt in verifieerbare credentials
Het W3C Verifiable Credentials Data Model 2.0, sinds 15 mei 2025 een W3C Recommendation, is gebouwd op JSON-LD. Elk credential begint met een @context waarvan de eerste waarde het gedeelde credentialvocabulaire is, zodat de termen die elk credential gemeen heeft, de uitgever, het subject, de geldigheidsdata en de statusinformatie, overal hetzelfde betekenen.
Alles daarbuiten komt uit een tweede vocabulaire. Een universiteit publiceert er een voor diplomavelden, een kamer van koophandel een voor velden over bedrijfsregistratie. Een verifier die om diploma's geeft laadt de eerste, een verifier die om bedrijfsgegevens geeft laadt de tweede, en geen van beide hoeft te veranderen wanneer de ander een veld toevoegt.
Dat is wat één credentialformaat in staat stelt gegevens te dragen die niemand had voorzien toen het formaat werd geschreven, en dat is de eigenschap die een open ecosysteem nodig heeft en een gesloten profiel niet.
Gekoppelde gegevens ondertekenen
Een credential moet ook worden ondertekend, en het datamodel laat daar bewust een keuze. Een omhullend bewijs verpakt het hele credential in een handtekeningcontainer zoals een JWT. De bytes worden precies ondertekend zoals ze zijn, dus alles wat ze onderweg herordent of anders opmaakt breekt de handtekening.
Een ingebed Data Integrity-bewijs werkt andersom. Het document wordt eerst in een canonieke vorm gebracht, gedefinieerd door RDF Dataset Canonicalization en sinds 21 mei 2024 een W3C Recommendation, en de handtekening dekt die vorm in plaats van de bytes. Omdat de canonieke vorm niet afhangt van sleutelvolgorde, witruimte of welke korte namen de @context toevallig gebruikt, overleeft de handtekening het opnieuw wegschrijven op een andere plek.
Waar het past in de EUDI Wallet
Niet waar de meeste mensen aannemen. Het Architecture and Reference Framework noemt twee credentialformaten voor de Europese wallet, SD-JWT VC en mdoc, en geen van beide is JSON-LD. Een organisatie die vandaag uitgeeft aan de EUDI Wallet komt onderweg geen @context tegen.
De redenering is uitvoerbaarheid. Beide formaten hebben een vaste vorm, één handtekeningmechanisme en geen document dat een verifier eerst moet ophalen voordat hij iets kan controleren. Voor een wallet die op een telefoon draait en een verifier die in milliseconden moet antwoorden, is dat meer waard dan een open vocabulaire.
JSON-LD verdient zijn plaats waar gegevens verder moeten reizen dan het ecosysteem dat ze heeft gedefinieerd: productpaspoorten en ketengegevens, pilots over sectoren heen, en credentialtypen die geen enkel centraal profiel ooit gaat opsommen. De twee werelden overlappen vaker dan ze concurreren, en organisaties die in beide werken ondersteunen uiteindelijk meestal allebei.
De andere JSON-LD, die u al hebt gebruikt
Lang voor credentials werd JSON-LD de manier waarop een website een zoekmachine vertelt waar een pagina over gaat. Een blok ervan in de paginabron, met het vocabulaire van schema.org, is wat van een pagina een herkend artikel, product, evenement of organisatie maakt. Deze pagina draagt er een.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD uitgelegd",
"description": "Wat JSON-LD toevoegt aan gewone JSON, hoe een @context elk veld één betekenis geeft en waar verifieerbare credentials het gebruiken.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "nl",
"mainEntityOfPage": "https://www.credenco.com/nl/explained/json-ld",
"author": {
"@type": "Organization",
"name": "Credenco",
"url": "https://www.credenco.com/"
},
"publisher": {
"@type": "Organization",
"name": "Credenco",
"logo": {
"@type": "ImageObject",
"url": "https://www.credenco.com/logo.svg"
}
}
}Het is hetzelfde formaat met een ander vocabulaire, en het is de helderste manier om het punt te zien. Niemand hier heeft iets afgesproken met welke zoekmachine dan ook. De @context wijst naar schema.org, de zoekmachine kent dat vocabulaire al, en de pagina wordt begrepen door een partij waarmee hij nooit heeft gesproken. Een credential dat een grens overgaat doet precies hetzelfde.
Wat het u kost
De context moet beschikbaar zijn. Een verifier die hem ophaalt op het moment van verificatie heeft een netwerkafhankelijkheid toegevoegd aan een beveiligingsbeslissing, en wie dat document serveert kan veranderen wat het credential lijkt te zeggen. Echte implementaties leggen de contexten vast die ze accepteren en leveren ze mee met de software in plaats van ze live op te halen.
Canonicalisatie is ook echt werk. Een document voor het ondertekenen in een canonieke dataset omzetten is aanzienlijk meer code dan bytes ondertekenen, en de faalgevallen zijn subtiel. De documenten zijn bovendien groter, wat gaat tellen op een QR-code of bij een NFC-tik.
Dat alles maakt JSON-LD niet de verkeerde keuze. Het maakt het een keuze: betaal voor open vocabulaires waar gegevens de afspraak moeten overleven die ze heeft voortgebracht, en sla ze over waar een vast profiel al alles zegt wat de twee partijen nodig hebben.
Wat dit voor u betekent
Uitgever
Uitgeven aan de EUDI Wallet betekent SD-JWT VC of mdoc, en JSON-LD komt er nooit aan te pas. Uitgeven aan een W3C-ecosysteem maakt uw @context een langetermijnverplichting: het is de publieke definitie van uw velden, en hem veranderen breekt elke verifier die de oude heeft gecachet.
Verifier
Bepaal welke contexten u accepteert en lever ze mee met uw software. Er een ophalen tijdens verificatie maakt een externe server onderdeel van uw beveiligingsbeslissing en zet een netwerkaanroep midden in uw responstijd.
Ontwikkelaar
Lees een JSON-LD-document als gewone JSON wanneer u alleen een veld nodig hebt, en pak pas een volledige processor wanneer u echt uitklapt of canoniseert. Het meeste van de complexiteit die mensen aan JSON-LD toeschrijven zit in het ondertekenpad, niet in het leespad.
Gerelateerde termen
Veelgestelde vragen
Is JSON-LD nog steeds gewoon JSON?
Ja. Elk JSON-LD-document is geldige JSON, en software die alleen een veld hoeft te lezen kan het als zodanig behandelen. De extra machinerie komt pas in beeld wanneer u een document uitklapt tot zijn volledige vorm of het canoniseert om te ondertekenen, wat de meeste code die een credential leest nooit doet.
Gebruikt de EUDI Wallet JSON-LD?
Nee. Het Architecture and Reference Framework noemt SD-JWT VC en mdoc als credentialformaten, en geen van beide gebruikt JSON-LD. Het is van belang voor W3C-ecosystemen met verifieerbare credentials, productpaspoorten en ketengegevens, en niet voor de Europese wallet zelf.
Haalt een verifier de @context elke keer op?
Dat hoort niet. Een context ophalen tijdens verificatie zet een netwerkaanroep midden in een beveiligingsbeslissing en geeft een externe server de mogelijkheid om te veranderen wat het document lijkt te zeggen. Implementaties leggen de contexten vast die ze accepteren en leveren ze mee met de software, wat ook de vertraging wegneemt.
Is dit dezelfde JSON-LD die zoekmachines lezen?
Hetzelfde formaat met een ander vocabulaire. Gestructureerde gegevens op een webpagina laten hun @context naar schema.org wijzen, terwijl een credential die naar het credentialvocabulaire laat wijzen en naar wat er verder nodig is. De verwerkingsregels zijn in beide gevallen identiek.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen rechtstreeks de specificaties van het W3C.