JSON-LD
JSON-LD è normale JSON con un campo in più, @context, che dice che cosa significano gli altri campi. Il contesto associa ogni nome di campo abbreviato a un identificatore univoco a livello mondiale, di norma un URL pubblicato da chi ha definito il vocabolario, così un sistema che non ha mai visto quei dati riesce comunque a capire che cosa gli viene detto.
Il JSON normale dice come i dati sono scritti, non che cosa significano. Un campo chiamato name può contenere una persona, un'azienda o un prodotto, e due sistemi possono entrambi emettere JSON valido e restare in disaccordo su ogni suo campo. Quel divario si colma di norma con un accordo scritto fra le due parti, che funziona per una integrazione e smette di funzionare quando una credenziale emessa in un paese deve essere letta da un verificatore di un altro paese con cui nessuno ha parlato in anticipo.
JSON-LD lo colma dentro il documento stesso. Il @context associa ogni nome di campo abbreviato a un identificatore univoco a livello mondiale, così il campo resta leggibile per una persona e diventa inequivocabile per una macchina. Nessuno dei valori cambia, e chi riceve il documento senza riconoscere il vocabolario può comunque leggerlo come normale JSON e ignorare il resto. JSON-LD 1.0 è diventato W3C Recommendation il 16 gennaio 2014, e la versione 1.1 è seguita il 16 luglio 2020.
Il W3C Verifiable Credentials Data Model 2.0 è costruito su di esso. Ogni credenziale si apre con un @context il cui primo valore è il vocabolario condiviso delle credenziali, così l'emittente, il soggetto, le date di validità e le informazioni di stato significano la stessa cosa ovunque, e ogni ulteriore vocabolario fornisce i campi di cui ha bisogno un tipo specifico di credenziale.
Firmare un documento di dati collegati è una scelta fra due meccanismi. Una prova avvolgente come un JWT firma i byte esattamente come sono, perciò qualunque cosa li riordini o li riformatti lungo il percorso rompe la firma. Una prova Data Integrity incorporata firma invece una forma canonica, definita da RDF Dataset Canonicalization, ed è questo che permette alla firma di sopravvivere a una riscrittura altrove.
Non è uno dei formati di credenziale dell'EUDI Wallet. L'Architecture and Reference Framework indica SD-JWT VC e mdoc, e nessuno dei due usa JSON-LD, perciò un'organizzazione che emette verso il portafoglio europeo non incontrerà mai un @context. JSON-LD si guadagna il suo posto dove i dati devono viaggiare oltre l'ecosistema che li ha definiti: implementazioni di credenziali W3C, passaporti di prodotto e dati della catena di fornitura.
Lo stesso formato è anche il modo in cui un sito web dice a un motore di ricerca di che cosa parla una pagina, con il @context che punta a schema.org invece che a un vocabolario di credenziali. Le regole di elaborazione sono identiche nei due casi, il che rende i dati strutturati il posto più facile per vedere che cosa porta davvero un contesto.
Leggi la spiegazione completa
Questa pagina offre la definizione breve. La nostra spiegazione mostra che cosa significa in pratica: chi è coinvolto, come funziona e che cosa cambia per la vostra organizzazione.
JSON-LD spiegatoJSON-LD è uno dei formati di credenziale dell'EUDI Wallet?
No. L'Architecture and Reference Framework indica SD-JWT VC e mdoc, e nessuno dei due è un formato JSON-LD, perciò un portafoglio o un verificatore costruiti per le regole europee non hanno bisogno di alcun processore JSON-LD.
Si tratta di una scelta di perimetro, non di un verdetto sul formato. Entrambi i formati indicati dal quadro hanno una forma fissa, un solo meccanismo di firma e nessun documento che un verificatore debba andare a recuperare prima di poter controllare qualcosa, ed è questo che premiano un telefono e un tempo di risposta misurato in millisecondi. JSON-LD risponde a un'altra domanda, cioè come i dati conservino il loro significato fuori dall'ecosistema che li ha definiti, e le organizzazioni che lavorano in entrambi i mondi finiscono di solito per supportarli tutti e due.
Qual è la differenza fra JSON-LD e il JSON normale?
Nessuna nel modo in cui il documento è scritto: ogni documento JSON-LD è JSON valido, e un software che ne ha bisogno di un solo campo può trattarlo come tale. La differenza è il @context, che associa ogni nome di campo a un identificatore definito a livello mondiale, così il significato dei dati viaggia con il documento invece di vivere in una specifica che le due parti dovevano concordare in anticipo.
Il macchinario aggiuntivo conta solo quando un documento viene espanso nella sua forma completa o canonicalizzato per la firma, passaggi che un verificatore che legge una singola affermazione non esegue mai. Il costo vero sta altrove: il contesto deve essere disponibile, e un verificatore che lo recupera mentre verifica ha messo una chiamata di rete e un server remoto dentro una decisione di sicurezza. Le implementazioni fissano i contesti che accettano e li distribuiscono con il software.