JSON-LD
JSON-LD är vanlig JSON med ett extra fält, @context, som säger vad de övriga fälten betyder. Kontexten kopplar varje kort fältnamn till en globalt unik identifierare, normalt en URL som publicerats av den som definierade vokabulären, så att ett system som aldrig sett dessa data ändå kan lista ut vad det blir berättat.
Vanlig JSON säger hur data skrivs ned, inte vad de betyder. Ett fält som heter name kan innehålla en person, ett företag eller en produkt, och två system kan båda skicka giltig JSON och ändå vara oense om varje enskilt fält i den. Det glappet täpps normalt till med ett skriftligt avtal mellan de två parterna, vilket fungerar för en integration och slutar fungera när ett intyg utfärdat i ett land måste läsas av en verifierare i ett annat som ingen talat med i förväg.
JSON-LD täpper till det inuti själva dokumentet. @context kopplar varje kort fältnamn till en globalt unik identifierare, så att fältet förblir läsbart för en människa och blir entydigt för en maskin. Inget av värdena ändras, och en mottagare som inte känner igen vokabulären kan fortfarande läsa dokumentet som vanlig JSON och bortse från resten. JSON-LD 1.0 blev en W3C Recommendation den 16 januari 2014, och version 1.1 följde den 16 juli 2020.
W3C Verifiable Credentials Data Model 2.0 är byggd på det. Varje intyg inleds med en @context vars första värde är den gemensamma intygsvokabulären, så att utfärdaren, subjektet, giltighetsdatumen och statusinformationen betyder samma sak överallt, och varje ytterligare vokabulär levererar de fält som en viss intygstyp behöver.
Att signera ett dokument med länkade data är ett val mellan två mekanismer. Ett omslutande bevis som en JWT signerar byten exakt som de är, så allt som ordnar om eller formaterar om dem på vägen bryter signaturen. Ett inbäddat Data Integrity-bevis signerar i stället en kanonisk form, definierad av RDF Dataset Canonicalization, och det är det som låter signaturen överleva att dokumentet skrivs ut på nytt någon annanstans.
Det är inget av EUDI Wallets intygsformat. Architecture and Reference Framework pekar ut SD-JWT VC och mdoc, och inget av dem använder JSON-LD, så en organisation som utfärdar till den europeiska plånboken kommer aldrig att möta en @context. JSON-LD gör nytta där data måste resa bortom det ekosystem som definierade dem: utrullningar av W3C-intyg, produktpass och data i leveranskedjan.
Samma format är också hur en webbplats talar om för en sökmotor vad en sida handlar om, med @context som pekar på schema.org i stället för på en intygsvokabulär. Behandlingsreglerna är identiska i båda fallen, vilket gör strukturerade data till det enklaste stället att se vad en kontext faktiskt ger dig.
Läs hela förklaringen
Den här sidan ger den korta definitionen. Vår förklaring visar vad det innebär i praktiken: vilka som är inblandade, hur det fungerar och vad som förändras för er organisation.
JSON-LD förklaratRelaterade termer
Är JSON-LD ett av EUDI Wallets intygsformat?
Nej. Architecture and Reference Framework pekar ut SD-JWT VC och mdoc, och inget av dem är ett JSON-LD-format, så en plånbok eller en verifierare byggd för de europeiska reglerna behöver ingen JSON-LD-processor alls.
Det är en avgränsning, inte en dom över formatet. Båda formaten som ramverket pekar ut har en fast form, en enda signaturmekanism och inget dokument som en verifierare måste hämta innan den kan kontrollera något, och det är precis vad en telefon och en svarstid mätt i millisekunder belönar. JSON-LD svarar på en annan fråga, nämligen hur data behåller sin betydelse utanför det ekosystem som definierade dem, och organisationer som arbetar i båda världarna slutar oftast med att stödja båda.
Vad är skillnaden mellan JSON-LD och vanlig JSON?
Ingenting i hur dokumentet är skrivet: varje JSON-LD-dokument är giltig JSON, och programvara som bara behöver ett fält ur det kan behandla det så. Skillnaden är @context, som kopplar varje fältnamn till en globalt definierad identifierare, så att betydelsen hos data reser med dokumentet i stället för att ligga i en specifikation som de två parterna måste komma överens om i förväg.
Det extra maskineriet spelar roll först när ett dokument expanderas till sin fulla form eller kanoniseras för signering, steg som en verifierare som läser ett enda påstående aldrig utför. Den verkliga kostnaden ligger någon annanstans: kontexten måste vara tillgänglig, och en verifierare som hämtar den under verifieringen har placerat ett nätverksanrop och en fjärrserver mitt i ett säkerhetsbeslut. Implementationer låser de kontexter de godtar och levererar dem med programvaran i stället.