JSON-LD
JSON-LD er almindelig JSON med ét ekstra felt, @context, der fortæller, hvad de øvrige felter betyder. Konteksten knytter hvert kort feltnavn til en globalt entydig identifikator, normalt en URL udgivet af den, som definerede vokabularet, så et system, der aldrig har set dataene før, alligevel kan regne ud, hvad det får fortalt.
Almindelig JSON fortæller, hvordan data skrives ned, ikke hvad de betyder. Et felt, der hedder name, kan indeholde en person, en virksomhed eller et produkt, og to systemer kan begge sende gyldig JSON og stadig være uenige om hvert eneste felt i den. Det hul lukkes normalt med en skriftlig aftale mellem de to parter, hvilket virker for én integration og holder op med at virke, så snart et credential udstedt i ét land skal læses af en verifier i et andet, som ingen har talt med på forhånd.
JSON-LD lukker det inde i selve dokumentet. @context knytter hvert kort feltnavn til en globalt entydig identifikator, så feltet forbliver læsbart for et menneske og bliver utvetydigt for en maskine. Ingen af værdierne ændrer sig, og en modtager, der ikke kender vokabularet, kan stadig læse dokumentet som almindelig JSON og se bort fra resten. JSON-LD 1.0 blev en W3C Recommendation den 16. januar 2014, og version 1.1 fulgte den 16. juli 2020.
W3C Verifiable Credentials Data Model 2.0 er bygget på det. Hvert credential åbner med en @context, hvis første værdi er det fælles credential-vokabular, så udstederen, subjektet, gyldighedsdatoerne og statusoplysningerne betyder det samme overalt, og ethvert yderligere vokabular leverer de felter, som én bestemt credential-type har brug for.
At signere et linked data-dokument er et valg mellem to mekanismer. Et omsluttende bevis som en JWT signerer bytene præcis som de er, så alt, der omrokerer eller omformaterer dem undervejs, bryder signaturen. Et indlejret Data Integrity-bevis signerer i stedet en kanonisk form, defineret af RDF Dataset Canonicalization, og det er dét, der lader signaturen overleve, at dokumentet skrives ud igen et andet sted.
Det er ingen af EUDI Wallets credential-formater. Architecture and Reference Framework udpeger SD-JWT VC og mdoc, og ingen af dem bruger JSON-LD, så en organisation, der udsteder til den europæiske tegnebog, møder aldrig en @context. JSON-LD gør nytte dér, hvor data skal rejse ud over det økosystem, der definerede dem: udrulninger af W3C-credentials, produktpas og data i forsyningskæden.
Samme format er også måden, hvorpå et websted fortæller en søgemaskine, hvad en side handler om, hvor @context peger på schema.org i stedet for på et credential-vokabular. Behandlingsreglerne er identiske i begge tilfælde, hvilket gør strukturerede data til det nemmeste sted at se, hvad en kontekst faktisk giver dig.
Læs hele forklaringen
Denne side giver den korte definition. Vores forklaring viser, hvad det betyder i praksis: hvem der er involveret, hvordan det fungerer, og hvad der ændrer sig for din organisation.
JSON-LD forklaretRelaterede begreber
Er JSON-LD et af EUDI Wallets credential-formater?
Nej. Architecture and Reference Framework udpeger SD-JWT VC og mdoc, og ingen af dem er et JSON-LD-format, så en tegnebog eller en verifier bygget til de europæiske regler har slet ikke brug for en JSON-LD-processor.
Det er en afgrænsning, ikke en dom over formatet. Begge de formater, rammeværket udpeger, har en fast form, én signaturmekanisme og ingen dokumenter, en verifier skal hente, før den kan kontrollere noget, og det er netop dét, en telefon og en svartid målt i millisekunder belønner. JSON-LD svarer på et andet spørgsmål, nemlig hvordan data bevarer deres betydning uden for det økosystem, der definerede dem, og organisationer, der arbejder i begge verdener, ender som regel med at understøtte begge.
Hvad er forskellen mellem JSON-LD og almindelig JSON?
Intet i, hvordan dokumentet er skrevet: hvert JSON-LD-dokument er gyldig JSON, og software, der kun har brug for ét felt fra det, kan behandle det sådan. Forskellen er @context, der knytter hvert feltnavn til en globalt defineret identifikator, så betydningen af dataene rejser med dokumentet i stedet for at ligge i en specifikation, de to parter skulle aftale på forhånd.
Det ekstra maskineri betyder først noget, når et dokument udvides til sin fulde form eller kanoniseres med henblik på signering, trin som en verifier, der læser én enkelt påstand, aldrig udfører. Den virkelige omkostning ligger et andet sted: konteksten skal være tilgængelig, og en verifier, der henter den under verifikationen, har placeret et netværkskald og en fjernserver midt i en sikkerhedsbeslutning. Implementeringer fastlåser de kontekster, de accepterer, og leverer dem med softwaren i stedet.