JSON-LD explicat
JSON-LD este JSON obișnuit cu o linie în plus care spune ce înseamnă câmpurile. Acea linie transformă un nume de câmp local într-unul definit global, astfel încât un sistem care nu v-a văzut niciodată datele să poată totuși înțelege despre ce vorbiți. Este un standard W3C din 2014, este modul în care motoarele de căutare citesc chiar această pagină și este temelia modelului de date W3C pentru acreditări verificabile.
Problema JSON-ului obișnuit
JSON spune cum sunt scrise datele. Nu spune nimic despre ce înseamnă ele. Un câmp numit name poate fi o persoană, o companie sau un produs. Un câmp numit id poate fi un număr de client, un număr de pașaport sau un rând din baza de date a cuiva. Două sisteme pot produce amândouă JSON perfect valid și totuși să nu fie de acord asupra niciunui câmp din el.
În practică, acel gol se umple printr-un acord. Cele două părți consemnează ce înseamnă câmpurile și își construiesc software-ul în consecință. Funcționează pentru o integrare, devine scump la zece și încetează complet să funcționeze atunci când o acreditare emisă într-o țară trebuie înțeleasă de un verificator din alta, cu care nimeni nu a vorbit dinainte.
Ce face @context
JSON-LD umple acel gol chiar în interiorul documentului. Un @context asociază fiecărui nume scurt de câmp un identificator unic la nivel mondial, de regulă un URL controlat de cel care a definit vocabularul. Câmpul rămâne scurt și lizibil pentru un om și devine lipsit de ambiguitate pentru o mașină.
JSON obișnuit
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Valid, lizibil și lipsit de sens pentru oricine nu a fost informat dinainte despre ce ar trebui să conțină câmpurile.
Aceleași date ca JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Fiecare câmp indică acum o definiție publicată, astfel încât un sistem care nu a văzut niciodată acest document îl poate citi totuși corect.
- @context numește vocabularul în care este definit fiecare câmp al documentului.
- @type spune ce fel de lucru descrie documentul, pentru ca din acel vocabular să fie alese definițiile potrivite.
Nimic din datele propriu-zise nu se schimbă. Aceleași valori, în aceeași formă, poartă acum o trimitere la definiția fiecărui câmp. Un sistem receptor care recunoaște vocabularul știe exact ce a primit, iar unul care nu îl recunoaște poate citi în continuare documentul ca JSON obișnuit și ignora restul.
Asta e toată ideea. Sensul călătorește odată cu documentul, în loc să stea într-o specificație asupra căreia cele două părți trebuiau să cadă de acord în prealabil.
Unde apare în acreditările verificabile
W3C Verifiable Credentials Data Model 2.0, W3C Recommendation din 15 mai 2025, este construit pe JSON-LD. Fiecare acreditare începe cu un @context a cărui primă valoare este vocabularul comun al acreditărilor, astfel încât termenii pe care toate acreditările îi au în comun, emitentul, subiectul, datele de valabilitate și informațiile de stare, să însemne același lucru peste tot.
Tot ce depășește asta vine dintr-un al doilea vocabular. O universitate publică unul pentru câmpurile diplomelor, o cameră de comerț unul pentru câmpurile de înregistrare a firmelor. Un verificator interesat de diplome îl încarcă pe primul, unul interesat de date despre firme îl încarcă pe al doilea, și niciunul nu trebuie schimbat când celălalt adaugă un câmp.
Asta permite unui singur format de acreditare să poarte date pe care nimeni nu le-a anticipat când formatul a fost scris, iar aceasta este proprietatea de care un ecosistem deschis are nevoie și un profil închis nu.
Semnarea datelor legate
O acreditare trebuie și semnată, iar modelul de date lasă acolo în mod deliberat o alegere. O dovadă învelitoare împachetează întreaga acreditare într-un container de semnătură precum un JWT. Octeții sunt semnați exact așa cum sunt, deci orice îi reordonează sau îi reformatează pe drum rupe semnătura.
O dovadă Data Integrity încorporată funcționează invers. Documentul este adus mai întâi la o formă canonică, definită de RDF Dataset Canonicalization și W3C Recommendation din 21 mai 2024, iar semnătura acoperă acea formă în loc de octeți. Pentru că forma canonică nu depinde de ordinea cheilor, de spații sau de ce nume scurte folosește @context, semnătura supraviețuiește rescrierii documentului în altă parte.
Unde se potrivește în EUDI Wallet
Nu acolo unde presupun cei mai mulți. Architecture and Reference Framework indică două formate de acreditare pentru portofelul european, SD-JWT VC și mdoc, iar niciunul dintre ele nu este JSON-LD. O organizație care emite astăzi către EUDI Wallet nu va întâlni niciun @context pe drum.
Motivul ține de posibilitatea de implementare. Ambele formate au o structură fixă, un singur mecanism de semnătură și niciun document pe care un verificator să fie nevoit să îl aducă înainte de a putea verifica ceva. Pentru un portofel care rulează pe un telefon și un verificator care trebuie să răspundă în milisecunde, asta valorează mai mult decât un vocabular deschis.
JSON-LD își merită locul acolo unde datele trebuie să călătorească dincolo de ecosistemul care le-a definit: pașapoarte de produs și date ale lanțului de aprovizionare, proiecte-pilot intersectoriale și tipuri de acreditare pe care niciun profil central nu le va enumera vreodată. Cele două lumi se suprapun mai des decât concurează, iar organizațiile care lucrează în ambele ajung de obicei să le susțină pe amândouă.
Celălalt JSON-LD, cel pe care l-ați folosit deja
Cu mult înainte de acreditări, JSON-LD a devenit modul în care un site web îi spune unui motor de căutare despre ce este o pagină. Un bloc de JSON-LD în sursa paginii, folosind vocabularul schema.org, este ceea ce transformă o pagină într-un articol, produs, eveniment sau organizație recunoscute. Această pagină poartă un astfel de bloc.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD explicat",
"description": "Ce adaugă JSON-LD peste JSON-ul obișnuit, cum un @context dă fiecărui câmp un singur sens și unde îl folosesc acreditările verificabile.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "ro",
"mainEntityOfPage": "https://www.credenco.com/ro/explained/json-ld",
"author": {
"@type": "Organization",
"name": "Credenco",
"url": "https://www.credenco.com/"
},
"publisher": {
"@type": "Organization",
"name": "Credenco",
"logo": {
"@type": "ImageObject",
"url": "https://www.credenco.com/logo.svg"
}
}
}Este același format cu un vocabular diferit și este cel mai limpede mod de a vedea ideea. Nimeni de aici nu a convenit nimic cu vreun motor de căutare. @context indică schema.org, motorul de căutare cunoaște deja acel vocabular, iar pagina este înțeleasă de o parte cu care nu a vorbit niciodată. O acreditare care trece o graniță face exact același lucru.
Cât vă costă
Contextul trebuie să fie disponibil. Un verificator care îl aduce în momentul verificării a adăugat o dependență de rețea unei decizii de securitate, iar cine servește acel document poate schimba ce pare să spună acreditarea. Implementările reale fixează contextele pe care le acceptă și le livrează cu software-ul, în loc să le rezolve în timp real.
Nici canonizarea nu e puțin lucru. Transformarea unui document într-un set de date canonic înainte de semnare înseamnă considerabil mai mult cod decât semnarea octeților, iar modurile în care poate eșua sunt subtile. Documentele sunt și mai mari, ceea ce începe să conteze pe un cod QR sau la o atingere NFC.
Nimic din toate acestea nu face din JSON-LD alegerea greșită. Îl face o alegere: plătiți pentru vocabulare deschise acolo unde datele trebuie să supraviețuiască acordului care le-a creat, și renunțați la ele acolo unde un profil fix spune deja tot ce le trebuie celor două părți.
Ce înseamnă asta pentru dumneavoastră
Emitent
A emite către EUDI Wallet înseamnă SD-JWT VC sau mdoc, iar JSON-LD nu apare niciodată. A emite către un ecosistem W3C face din @context-ul dumneavoastră un angajament pe termen lung: este definiția publică a câmpurilor dumneavoastră, iar schimbarea lui strică orice verificator care a păstrat în cache versiunea veche.
Verificator
Decideți ce contexte acceptați și livrați-le împreună cu software-ul dumneavoastră. Aducerea unuia în timpul verificării face dintr-un server la distanță o parte a deciziei dumneavoastră de securitate și pune un apel de rețea în mijlocul timpului dumneavoastră de răspuns.
Dezvoltator
Citiți un document JSON-LD ca pe JSON obișnuit când tot ce vă trebuie este un câmp, și recurgeți la un procesor complet doar acolo unde chiar extindeți sau canonizați. Cea mai mare parte a complexității atribuite JSON-LD stă în calea semnării, nu în cea a citirii.
Termeni conexi
Întrebări frecvente
JSON-LD este în continuare doar JSON?
Da. Orice document JSON-LD este JSON valid, iar un software care are nevoie doar să citească un câmp îl poate trata ca atare. Mecanismul suplimentar intră în joc abia când extindeți un document la forma sa completă sau îl canonizați pentru semnare, lucru pe care majoritatea codului care citește o acreditare nu îl face niciodată.
EUDI Wallet folosește JSON-LD?
Nu. Architecture and Reference Framework indică SD-JWT VC și mdoc drept formate de acreditare, iar niciunul dintre ele nu folosește JSON-LD. Contează pentru ecosistemele W3C de acreditări verificabile, pentru pașapoartele de produs și pentru datele lanțului de aprovizionare, nu pentru portofelul european în sine.
Un verificator descarcă @context de fiecare dată?
Nu ar trebui. Aducerea unui context în timpul verificării plasează un apel de rețea în mijlocul unei decizii de securitate și oferă unui server la distanță posibilitatea de a schimba ce pare să spună documentul. Implementările fixează contextele pe care le acceptă și le livrează împreună cu software-ul, ceea ce elimină și latența.
Este același JSON-LD pe care îl citesc motoarele de căutare?
Același format cu un vocabular diferit. Datele structurate de pe o pagină web își îndreaptă @context spre schema.org, în timp ce o acreditare îl îndreaptă spre vocabularul acreditărilor și spre ce altceva mai are nevoie. Regulile de procesare sunt identice în ambele cazuri.
Surse
Această pagină are caracter informativ și nu constituie consultanță juridică. Pentru îndrumări cu valoare oficială, consultați direct specificațiile W3C.