JSON-LD
JSON-LD to zwykły JSON z jednym dodatkowym polem, @context, które mówi, co znaczą pozostałe pola. Kontekst przypisuje każdej skróconej nazwie pola globalnie unikalny identyfikator, zwykle adres URL opublikowany przez tego, kto zdefiniował słownik, dzięki czemu system, który nigdy wcześniej nie widział tych danych, i tak zorientuje się, co mu się mówi.
Zwykły JSON mówi, jak dane są zapisane, a nie co znaczą. Pole o nazwie name może zawierać osobę, firmę albo produkt, a dwa systemy mogą oba wysyłać poprawny JSON i mimo to nie zgadzać się co do każdego jego pola. Tę lukę zamyka się zwykle pisemną umową między dwiema stronami, co działa przy jednej integracji i przestaje działać, gdy poświadczenie wydane w jednym kraju musi odczytać weryfikator w innym, z którym nikt wcześniej nie rozmawiał.
JSON-LD zamyka ją wewnątrz samego dokumentu. @context przypisuje każdej skróconej nazwie pola globalnie unikalny identyfikator, dzięki czemu pole pozostaje czytelne dla człowieka i staje się jednoznaczne dla maszyny. Żadna z wartości się nie zmienia, a odbiorca, który nie rozpoznaje słownika, nadal może przeczytać dokument jak zwykły JSON i pominąć resztę. JSON-LD 1.0 stał się W3C Recommendation 16 stycznia 2014 roku, a wersja 1.1 pojawiła się 16 lipca 2020 roku.
W3C Verifiable Credentials Data Model 2.0 jest na nim zbudowany. Każde poświadczenie zaczyna się od @context, którego pierwszą wartością jest wspólny słownik poświadczeń, więc wydawca, podmiot, daty ważności i informacja o statusie znaczą wszędzie to samo, a każdy dalszy słownik dostarcza pól, których potrzebuje jeden konkretny typ poświadczenia.
Podpisanie dokumentu z danymi powiązanymi to wybór między dwoma mechanizmami. Dowód otaczający, taki jak JWT, podpisuje bajty dokładnie w takiej postaci, w jakiej są, więc wszystko, co po drodze zmieni ich kolejność lub formatowanie, łamie podpis. Osadzony dowód Data Integrity podpisuje zamiast tego postać kanoniczną, zdefiniowaną przez RDF Dataset Canonicalization, i właśnie to pozwala podpisowi przetrwać ponowne zapisanie dokumentu gdzie indziej.
Nie jest żadnym z formatów poświadczeń EUDI Wallet. Architecture and Reference Framework wskazuje SD-JWT VC i mdoc, a żaden z nich nie używa JSON-LD, więc organizacja wydająca do europejskiego portfela nigdy nie napotka @context. JSON-LD zarabia na swoje miejsce tam, gdzie dane muszą podróżować poza ekosystem, który je zdefiniował: wdrożenia poświadczeń W3C, paszporty produktów i dane łańcucha dostaw.
Ten sam format to również sposób, w jaki witryna mówi wyszukiwarce, o czym jest strona, przy czym @context wskazuje schema.org, a nie słownik poświadczeń. Zasady przetwarzania są w obu przypadkach identyczne, co sprawia, że dane strukturalne są najłatwiejszym miejscem, by zobaczyć, co naprawdę daje kontekst.
Przeczytaj pełne wyjaśnienie
Ta strona podaje krótką definicję. Nasze wyjaśnienie pokazuje, co to oznacza w praktyce: kto bierze w tym udział, jak to działa i co zmienia się dla Twojej organizacji.
JSON-LD wyjaśnionyCzy JSON-LD jest jednym z formatów poświadczeń EUDI Wallet?
Nie. Architecture and Reference Framework wskazuje SD-JWT VC i mdoc, a żaden z nich nie jest formatem JSON-LD, więc portfel ani weryfikator zbudowany pod europejskie przepisy nie potrzebuje w ogóle procesora JSON-LD.
To decyzja o zakresie, a nie wyrok na format. Oba formaty wskazane przez ramy mają stałą postać, jeden mechanizm podpisu i żadnego dokumentu, po który weryfikator musiałby sięgnąć, zanim cokolwiek sprawdzi, a właśnie to nagradzają telefon i czas odpowiedzi mierzony w milisekundach. JSON-LD odpowiada na inne pytanie, mianowicie jak dane zachowują znaczenie poza ekosystemem, który je zdefiniował, a organizacje działające w obu światach zwykle kończą na wspieraniu obu.
Czym różni się JSON-LD od zwykłego JSON-a?
Niczym w sposobie zapisu dokumentu: każdy dokument JSON-LD jest poprawnym JSON-em, a oprogramowanie, które potrzebuje z niego tylko jednego pola, może go tak traktować. Różnicą jest @context, który przypisuje każdej nazwie pola globalnie zdefiniowany identyfikator, dzięki czemu znaczenie danych podróżuje razem z dokumentem, zamiast tkwić w specyfikacji, którą obie strony musiały wcześniej uzgodnić.
Dodatkowa maszyneria ma znaczenie dopiero wtedy, gdy dokument jest rozwijany do pełnej postaci albo kanonizowany na potrzeby podpisu, a weryfikator czytający jedno oświadczenie nigdy tych kroków nie wykonuje. Prawdziwy koszt leży gdzie indziej: kontekst musi być dostępny, a weryfikator, który pobiera go w trakcie weryfikacji, umieścił wywołanie sieciowe i zdalny serwer wewnątrz decyzji bezpieczeństwa. Implementacje przypinają akceptowane konteksty i dostarczają je razem z oprogramowaniem.