JSON-LD
JSON-LD este JSON obișnuit cu un câmp în plus, @context, care spune ce înseamnă celelalte câmpuri. Contextul asociază fiecărui nume scurt de câmp un identificator unic la nivel mondial, de regulă un URL publicat de cel care a definit vocabularul, astfel încât un sistem care nu a mai văzut acele date poate totuși înțelege ce i se spune.
JSON-ul obișnuit spune cum sunt scrise datele, nu ce înseamnă ele. Un câmp numit name poate conține o persoană, o companie sau un produs, iar două sisteme pot emite amândouă JSON valid și totuși să nu fie de acord asupra niciunui câmp din el. Golul se umple de obicei cu o înțelegere scrisă între cele două părți, care funcționează pentru o singură integrare și încetează să funcționeze atunci când o acreditare emisă într-o țară trebuie citită de un verificator din alta, cu care nimeni nu a vorbit dinainte.
JSON-LD îl umple chiar în interiorul documentului. @context asociază fiecărui nume scurt de câmp un identificator unic la nivel mondial, astfel încât câmpul rămâne lizibil pentru un om și devine lipsit de ambiguitate pentru o mașină. Niciuna dintre valori nu se schimbă, iar un destinatar care nu recunoaște vocabularul poate citi în continuare documentul ca JSON obișnuit și ignora restul. JSON-LD 1.0 a devenit W3C Recommendation la 16 ianuarie 2014, iar versiunea 1.1 a urmat la 16 iulie 2020.
W3C Verifiable Credentials Data Model 2.0 este construit pe el. Fiecare acreditare începe cu un @context a cărui primă valoare este vocabularul comun al acreditărilor, astfel încât emitentul, subiectul, datele de valabilitate și informațiile de stare înseamnă același lucru peste tot, iar orice vocabular suplimentar furnizează câmpurile de care are nevoie un anumit tip de acreditare.
Semnarea unui document cu date legate este o alegere între două mecanisme. O dovadă învelitoare precum un JWT semnează octeții exact așa cum sunt, deci orice îi reordonează sau îi reformatează pe drum rupe semnătura. O dovadă Data Integrity încorporată semnează în schimb o formă canonică, definită de RDF Dataset Canonicalization, iar asta este ceea ce permite semnăturii să supraviețuiască rescrierii documentului în altă parte.
Nu este niciunul dintre formatele de acreditare ale EUDI Wallet. Architecture and Reference Framework indică SD-JWT VC și mdoc, iar niciunul dintre ele nu folosește JSON-LD, așa că o organizație care emite către portofelul european nu va întâlni niciodată un @context. JSON-LD își merită locul acolo unde datele trebuie să călătorească dincolo de ecosistemul care le-a definit: implementări de acreditări W3C, pașapoarte de produs și date din lanțul de aprovizionare.
Același format este și modul în care un site web îi spune unui motor de căutare despre ce este o pagină, cu @context indicând spre schema.org în loc de un vocabular de acreditări. Regulile de procesare sunt identice în ambele cazuri, ceea ce face din datele structurate locul cel mai simplu pentru a vedea ce aduce de fapt un context.
Citiți explicația completă
Această pagină oferă definiția pe scurt. Explicația noastră arată ce înseamnă în practică: cine este implicat, cum funcționează și ce se schimbă pentru organizația dumneavoastră.
JSON-LD explicatEste JSON-LD unul dintre formatele de acreditare ale EUDI Wallet?
Nu. Architecture and Reference Framework indică SD-JWT VC și mdoc, iar niciunul dintre ele nu este un format JSON-LD, așa că un portofel sau un verificator construit pentru regulile europene nu are nevoie deloc de un procesor JSON-LD.
Este o decizie de domeniu de aplicare, nu un verdict asupra formatului. Ambele formate indicate de cadru au o formă fixă, un singur mecanism de semnare și niciun document pe care un verificator să fie nevoit să îl aducă înainte de a putea verifica ceva, iar exact asta răsplătesc un telefon și un timp de răspuns măsurat în milisecunde. JSON-LD răspunde la o altă întrebare, anume cum își păstrează datele sensul în afara ecosistemului care le-a definit, iar organizațiile care lucrează în ambele lumi ajung de obicei să le susțină pe amândouă.
Care este diferența dintre JSON-LD și JSON-ul obișnuit?
Niciuna în felul în care este scris documentul: orice document JSON-LD este JSON valid, iar software-ul care are nevoie doar de un câmp din el îl poate trata ca atare. Diferența este @context, care asociază fiecărui nume de câmp un identificator definit la nivel mondial, astfel încât sensul datelor călătorește odată cu documentul în loc să stea într-o specificație pe care cele două părți trebuiau să o convină dinainte.
Mecanismul suplimentar contează abia atunci când un document este extins la forma sa completă sau canonicalizat pentru semnare, pași pe care un verificator care citește o singură afirmație nu îi execută niciodată. Costul real este în altă parte: contextul trebuie să fie disponibil, iar un verificator care îl aduce în timp ce verifică a plasat un apel de rețea și un server la distanță în mijlocul unei decizii de securitate. Implementările fixează contextele pe care le acceptă și le livrează împreună cu software-ul.