JSON-LD
JSON-LD on tavallista JSONia yhdellä ylimääräisellä kentällä, @context, joka kertoo mitä muut kentät tarkoittavat. Konteksti yhdistää jokaisen lyhyen kentän nimen maailmanlaajuisesti yksilölliseen tunnisteeseen, tavallisesti URL-osoitteeseen jonka on julkaissut se joka sanaston määritteli, joten järjestelmä joka ei ole koskaan nähnyt näitä tietoja pystyy silti päättelemään mitä sille kerrotaan.
Tavallinen JSON kertoo miten tiedot kirjoitetaan muistiin, ei mitä ne tarkoittavat. Kenttä nimeltä name voi sisältää henkilön, yrityksen tai tuotteen, ja kaksi järjestelmää voivat kumpikin tuottaa kelvollista JSONia ja olla silti eri mieltä sen jokaisesta kentästä. Aukko paikataan tavallisesti osapuolten välisellä kirjallisella sopimuksella, joka toimii yhdelle integraatiolle ja lakkaa toimimasta heti kun yhdessä maassa myönnetty valtuustieto pitää lukea toisen maan todentajalle, jolle kukaan ei ole etukäteen puhunut.
JSON-LD paikkaa sen dokumentin sisällä. @context yhdistää jokaisen lyhyen kentän nimen maailmanlaajuisesti yksilölliseen tunnisteeseen, joten kenttä pysyy ihmisen luettavana ja muuttuu koneelle yksiselitteiseksi. Yksikään arvoista ei muutu, ja vastaanottaja joka ei tunnista sanastoa voi silti lukea dokumentin tavallisena JSONina ja jättää lopun huomiotta. JSON-LD 1.0:sta tuli W3C Recommendation 16. tammikuuta 2014, ja versio 1.1 seurasi 16. heinäkuuta 2020.
W3C Verifiable Credentials Data Model 2.0 on rakennettu sen varaan. Jokainen valtuustieto alkaa @contextilla, jonka ensimmäinen arvo on yhteinen valtuustietosanasto, joten myöntäjä, kohde, voimassaolopäivät ja tilatieto tarkoittavat kaikkialla samaa, ja jokainen lisäsanasto tuo ne kentät joita yksi tietty valtuustietotyyppi tarvitsee.
Linkitetyn datan dokumentin allekirjoittaminen on valinta kahden mekanismin välillä. Kuoreen kääräisevä todiste kuten JWT allekirjoittaa tavut täsmälleen sellaisina kuin ne ovat, joten mikä tahansa joka järjestää tai muotoilee ne matkalla uudelleen rikkoo allekirjoituksen. Upotettu Data Integrity -todiste allekirjoittaa sen sijaan kanonisen muodon, jonka määrittelee RDF Dataset Canonicalization, ja juuri se saa allekirjoituksen kestämään sen että dokumentti kirjoitetaan uudelleen muualla.
Se ei ole mikään EUDI Walletin valtuustietomuodoista. Architecture and Reference Framework nimeää SD-JWT VC:n ja mdocin, eikä kumpikaan käytä JSON-LD:tä, joten eurooppalaiseen lompakkoon myöntävä organisaatio ei kohtaa koskaan @contextia. JSON-LD ansaitsee paikkansa siellä missä tietojen on matkattava sen ekosysteemin ulkopuolelle joka ne määritteli: W3C-valtuustietojen käyttöönotot, tuotepassit ja toimitusketjun tiedot.
Sama muoto on myös se tapa jolla verkkosivusto kertoo hakukoneelle mistä sivu kertoo, jolloin @context osoittaa schema.orgiin eikä valtuustietosanastoon. Käsittelysäännöt ovat kummassakin tapauksessa samat, mikä tekee rakenteisesta datasta helpoimman paikan nähdä mitä konteksti oikeastaan tuo.
Lue koko selitys
Tämä sivu antaa lyhyen määritelmän. Selityksemme näyttää, mitä se tarkoittaa käytännössä: keitä siihen osallistuu, miten se toimii ja mikä muuttuu organisaatiollesi.
JSON-LD selitettynäAiheeseen liittyvät termit
Onko JSON-LD yksi EUDI Walletin valtuustietomuodoista?
Ei. Architecture and Reference Framework nimeää SD-JWT VC:n ja mdocin, eikä kumpikaan ole JSON-LD-muoto, joten eurooppalaisten sääntöjen mukaan rakennettu lompakko tai todentaja ei tarvitse lainkaan JSON-LD-käsittelijää.
Kyse on rajauksesta, ei tuomiosta muodosta. Molemmilla viitekehyksen nimeämillä muodoilla on kiinteä rakenne, yksi allekirjoitusmekanismi eikä yhtään dokumenttia jota todentajan pitäisi hakea ennen kuin se voi tarkistaa mitään, ja juuri sitä puhelin ja millisekunneissa mitattava vasteaika palkitsevat. JSON-LD vastaa toiseen kysymykseen, nimittäin siihen miten tiedot säilyttävät merkityksensä ne määritelleen ekosysteemin ulkopuolella, ja molemmissa maailmoissa toimivat organisaatiot päätyvät yleensä tukemaan kumpaakin.
Mitä eroa on JSON-LD:llä ja tavallisella JSONilla?
Ei mitään siinä miten dokumentti on kirjoitettu: jokainen JSON-LD-dokumentti on kelvollista JSONia, ja ohjelmisto joka tarvitsee siitä vain yhden kentän voi käsitellä sitä sellaisena. Ero on @context, joka yhdistää jokaisen kentän nimen maailmanlaajuisesti määriteltyyn tunnisteeseen, jolloin tietojen merkitys matkaa dokumentin mukana sen sijaan että se eläisi määrittelyssä josta osapuolten oli sovittava etukäteen.
Ylimääräisellä koneistolla on merkitystä vasta kun dokumentti laajennetaan täyteen muotoonsa tai kanonisoidaan allekirjoitusta varten, eikä yhtä väitettä lukeva todentaja tee näitä koskaan. Todellinen hinta on muualla: kontekstin on oltava saatavilla, ja todentaja joka hakee sen todennuksen aikana on sijoittanut verkkokutsun ja etäpalvelimen keskelle turvallisuuspäätöstä. Toteutukset kiinnittävät hyväksymänsä kontekstit ja toimittavat ne sen sijaan ohjelmiston mukana.