JSON-LD
JSON-LD is gewone JSON met één extra veld, @context, dat zegt wat de andere velden betekenen. De context koppelt elke korte veldnaam aan een wereldwijd unieke identificatie, normaal gesproken een URL gepubliceerd door degene die het vocabulaire heeft gedefinieerd, zodat een systeem dat de gegevens nooit eerder heeft gezien toch kan uitzoeken wat het te horen krijgt.
Gewone JSON zegt hoe gegevens worden opgeschreven, niet wat ze betekenen. Een veld dat name heet kan een persoon, een bedrijf of een product bevatten, en twee systemen kunnen allebei geldige JSON versturen en het toch over elk veld oneens zijn. Dat gat wordt normaal gesproken gedicht met een afspraak op papier tussen de twee partijen, wat werkt voor één koppeling en ophoudt te werken zodra een credential dat in het ene land is uitgegeven gelezen moet worden door een verifier in een ander land die niemand vooraf heeft gesproken.
JSON-LD dicht dat gat in het document zelf. De @context koppelt elke korte veldnaam aan een wereldwijd unieke identificatie, zodat het veld leesbaar blijft voor een mens en ondubbelzinnig wordt voor een machine. Geen van de waarden verandert, en een ontvanger die het vocabulaire niet herkent kan het document nog steeds als gewone JSON lezen en de rest negeren. JSON-LD 1.0 werd op 16 januari 2014 een W3C Recommendation, en versie 1.1 volgde op 16 juli 2020.
Het W3C Verifiable Credentials Data Model 2.0 is erop gebouwd. Elk credential begint met een @context waarvan de eerste waarde het gedeelde credentialvocabulaire is, zodat de uitgever, het subject, de geldigheidsdata en de statusinformatie overal hetzelfde betekenen, en elk verder vocabulaire levert de velden die één specifiek credentialtype nodig heeft.
Het ondertekenen van een linked-datadocument is een keuze tussen twee mechanismen. Een omhullend bewijs zoals een JWT ondertekent de bytes precies zoals ze zijn, dus alles wat ze onderweg herordent of anders opmaakt breekt de handtekening. Een ingebed Data Integrity-bewijs ondertekent in plaats daarvan een canonieke vorm, gedefinieerd door RDF Dataset Canonicalization, en dat is wat de handtekening het opnieuw wegschrijven op een andere plek laat overleven.
Het is geen van de credentialformaten van de EUDI Wallet. Het Architecture and Reference Framework noemt SD-JWT VC en mdoc, en geen van beide gebruikt JSON-LD, dus een organisatie die uitgeeft aan de Europese wallet komt nooit een @context tegen. JSON-LD verdient zijn plek waar gegevens verder moeten reizen dan het ecosysteem dat ze heeft gedefinieerd: implementaties van W3C-credentials, productpaspoorten en ketengegevens.
Hetzelfde formaat is ook hoe een website een zoekmachine vertelt waar een pagina over gaat, met de @context die naar schema.org wijst in plaats van naar een credentialvocabulaire. De verwerkingsregels zijn in beide gevallen identiek, wat structuurdata de makkelijkste plek maakt om te zien wat een context u eigenlijk oplevert.
Lees de volledige uitleg
Deze pagina geeft de korte definitie. Onze uitleg laat zien wat het in de praktijk betekent: wie erbij betrokken is, hoe het werkt en wat er verandert voor uw organisatie.
JSON-LD uitgelegdGerelateerde termen
Is JSON-LD een van de credentialformaten van de EUDI Wallet?
Nee. Het Architecture and Reference Framework noemt SD-JWT VC en mdoc, en geen van beide is een JSON-LD-formaat, dus een wallet of verifier die voor de Europese regels is gebouwd heeft helemaal geen JSON-LD-processor nodig.
Dat is een afbakening, geen oordeel over het formaat. Beide formaten die het framework noemt hebben een vaste vorm, één handtekeningmechanisme en geen document dat een verifier eerst moet ophalen voordat hij iets kan controleren, en dat is wat een telefoon en een responstijd in milliseconden belonen. JSON-LD beantwoordt een andere vraag, namelijk hoe gegevens hun betekenis behouden buiten het ecosysteem dat ze heeft gedefinieerd, en organisaties die in beide werelden werken ondersteunen uiteindelijk meestal allebei.
Wat is het verschil tussen JSON-LD en gewone JSON?
Niets in hoe het document is opgeschreven: elk JSON-LD-document is geldige JSON, en software die er maar één veld uit nodig heeft kan het ook zo behandelen. Het verschil is de @context, die elke veldnaam koppelt aan een wereldwijd gedefinieerde identificatie, zodat de betekenis van de gegevens met het document meereist in plaats van te leven in een specificatie waarover de twee partijen vooraf afspraken moesten maken.
De extra machinerie doet er pas toe wanneer een document wordt uitgeklapt naar zijn volledige vorm of gecanonicaliseerd om te ondertekenen, stappen die een verifier die één claim leest nooit uitvoert. De echte kosten zitten elders: de context moet beschikbaar zijn, en een verifier die hem ophaalt tijdens het verifiëren heeft een netwerkaanroep en een externe server midden in een beveiligingsbeslissing gezet. Implementaties leggen de contexten vast die ze accepteren en leveren ze in plaats daarvan mee met de software.