ERK'2022, Portorož, 64-67 64 Prototipni sistem samovladne identitete s tehnologijo Ethereum Rihard Maruˇ siˇ c, Matevˇ z Pustiˇ sek Univerza v Ljubljani, Fakulteta za elektrotehniko, Trˇ zaˇ ska 25, 1000 Ljubljana E-poˇ sta: rm3612@student.uni-lj.si, matevz.pustisek@fe.uni-lj.si A Self-Sovereign Identity Prototype System with Ethereum Abstract. There are many different ways and approaches to identity management in the digital world. This article focuses on a relatively new concept of identity manage- ment, called self-sovereign identity, which aims to give individuals more control over their identity and reduce dependency on centralised entities. The article includes a theoretical part, where the self- sovereign identity is presented in more detail, with de- scriptions of the basic building blocks and functionalities. The second part presents the creation of a simple pro- totype implementation of a self-sovereign identity, which contains only the basic functionalities and aims to present in some more detail the technological background of an example of such system. 1 Uvod ˇ Clanek se predvsem posveˇ ca ˇ se dokaj novemu konceptu samovladne identitete (ang. self-sovereign identity, SSI), katere cilj in potencial, ˇ ce se tehnologija uveljavi, postane bolj popularna in dozori, je predstavljati nekakˇ sen nov identifikacijski sloj interneta. Trenutni uveljavljeni sistemi upravljanja z identiteto, ki so poveˇ cini centralizirani ali delegirani, niso preno- sljivi in interoperabilni, nadzor nad podatki pa je v ro- kah ponudnikov storitev in identitete. Sistemi samovla- dne identitete pa stremijo k temu, da bi uporabniku dali ˇ cim veˇ c nadzora nad lastnimi podatki, ter komu, kako in kdaj jih bo predstavljal. Ponujali bi veˇ c zasebnosti in var- nejˇ se hranjenje identitete. Stremi tudi k decentralizaciji, ki postaja dandanes z veˇ canjem popularnosti tehnologije veriˇ zenja blokov (ang. blockchain) vedno veˇ cji predmet pogovora, ko se tudi zdi, da ljudje dajo vedno veˇ c pozor- nosti ter skrbi na zasebnost in varnost njihovih podatkov na spletu. Cilj ˇ clanka je bralcu predstaviti koncept samovladne identitete ter ga na kratko seznaniti s tehnoloˇ skim ozad- jem in razliˇ cnimi tehnologijami, ki stojijo za implemen- tacijo takih vrst sistemov identitet. Cilj je bil tudi izdelati prototipno, demonstracijsko reˇ sitev samovladne identi- tete. Reˇ sitev je zato tudi bolj poenostavljena, nekateri ele- menti so implementirani nekoliko drugaˇ ce, kot bi bili si- cer, saj reˇ sitev ni namenjena produkcijski uporabi, temveˇ c sluˇ zi za zgolj ˇ se globlje in laˇ zje razumevanje teh tehnolo- gij. 2 Samovladna identiteta Pri samovladni identiteti je uporabnik sam upravljalec nad lastno identiteto in ima nad njo veliko veˇ c nadzora kot pri drugih modelih upravljanja identitete. Uporab- nik se lahko odloˇ ci do kdaj, komu in katere informacije bo delil, prav tako samovladna identiteta stremi k ˇ cim veˇ cji decentralizaciji ter ˇ cim veˇ cji moˇ ci in avtonomiji na strani uporabnika. Koncept samovladne identitete je v doloˇ cenih pogledih zelo podoben danaˇ snjemu fiziˇ cnemu (nedigitalnemu) svetu upravljanja identitete, kjer ljudje poveˇ cini sami pri sebi v denarnicah hranimo na primer osebno izkaznico ali vozniˇ sko dovoljenje. To potem upo- rabimo za izkazovanje identitete v banki, ˇ ce banka seveda zaupa izdajatelju dokumenta.[1] Samovladna identiteta temelji na osnovnih gradnikih med katere spadajo decentralizirani identifikatorji (DID- ji), DID dokumenti, preverljiva potrdila oz. poverilnice ter digitalne denarnice. Za nekatere gradnike ˇ ze obsta- jajo raznorazni standardi, tu je mogoˇ ce smotrno izposta- viti standarde w3c-ja (ang. World Wide Web Consor- tium)[2][3]. Za veˇ cino interakcij, kjer je potrebno izkazovati dolo- ˇ cene trditve, so pomembne tri entitete - imetnik, izdaja- telj, preveritelj (ang. holder, issuer, verifier). Imetnik je entiteta, na katero se trditve nanaˇ sajo, izdajatelj je enti- teta, ki potrjuje, da so trditve resniˇ cne. Preveritelj pa je entiteta, ki za raznorazne namene zahteva trditve, kate- rih imetnik mora dokazati legitimnost in verodostojnost, izdajatelju pa zaupa, da drˇ zijo. 2.1 Decentralizirani identifikatorji Sistem temelji na asimetriˇ cni kriptografiji. DID je uni- katni identifikator, ki predstavlja uporabnika, nadzor nad njim pa lahko uporabnik kriptografsko dokaˇ ze. DID je URI, ki vodi do DID dokumenta. Pridobivanju DID do- kumenta zgolj z vedenjem zgolj DID-ja pravimo razreˇ s- evanje (ang. resolving). v DID dokumentu so podatki, ki opiˇ sejo lastnika DID-ja s podrobnejˇ simi informacijami. Med najpomembnejˇ se spadajo avtentikacijske metode s katerimi bo dokazal lastniˇ stvo nad DID-jem, konˇ cna toˇ c- ka storitve (ang. service endpoint - na primer omreˇ zni naslov ali ostali naˇ cini za vzpostavitev komunikacije z 65 lastnikom DID-ja) in javni kljuˇ ci s pomoˇ cjo katerih bo uporabnik kriptografsko dokazal lastniˇ stvo. DID-je lahko delimo na javne in zasebne. DID dokumenti javnih DID- jev, ki morajo biti razreˇ sljivi so ponavadi objavljeni na javnem mestu - pogosto se za to uporabi veriga blokov. Uporabnik nima samo enega DID-ja, ponavadi ima za vsako novo razmerje drugi DID.[4] 2.2 Preverljiva potrdila Preverljivo potrdilo je dokument, ki ga je mogoˇ ce kripto- grafsko preveriti in katerega izdajatelj je razviden. Upo- rabnik potrdila shranjuje sam pri sebi v svoji denarnici in jih uporablja za predstavljanje raznoraznim entitetam. Ker potrdilo hrani izkljuˇ cno uporabnik sam, ima tako veˇ c nadzora nad lastnimi podatki, komu jih bo predal in kdaj. Z implementacijo potrdil na naˇ cin, da podpirajo dokaz brez znanja (ang. zero-knowledge proof), se lahko doseˇ ze ˇ se veˇ cjo zasebnost uporabnika ter prepreˇ ci korelacijo.[5][3] 2.3 Digitalne denarnice Digitalne denarnice so prostor, kjer se shranjujejo vsi po- datki, potrebni za operiranje v ekosistemu samovladne identitete. Obstaja mnogo razliˇ cnih vrst denarnic, od sple- tnih aplikacij, do mobilnih aplikacij, raˇ cunalniˇ skih pro- gramov ali pa celo strojnih denarnic. Razlikujejo se tudi po namembnosti. Denarnica namenjena podjetju ali pa na primer napravi bo morala imeti dodatne funkcionalnosti, kot denarnica, ki je namenjena zgolj fiziˇ cni osebi. Prav tako poznamo denarnice s skrbniˇ stvom ali brez skrbniˇ stva. Varnost denarnice je kljuˇ cnega pomena, potrebna je do- bra enkripcija podatkov, prav tako je pomembna enostavna kreacija varnostnih kopij, saj izguba nad dostopom do de- narnice pomeni tudi izgubo identitete.[1] 3 Predstavitev reˇ sitve Cilj je bil izdelati poenostavljeno, prototipno razliˇ cico sistema samovladne identitete, ki bo omogoˇ cal podrob- nejˇ se razumevanje, kaj samovladna identiteta sploh je in kako deluje ter kaj se dogaja v ozadju, ni pa reˇ sitev na- menjena produkcijski uporabi. Reˇ sitev ima ˇ se vedno vse jedrne sestavne dele in omogoˇ ca vse osnovne funkcional- nosti, ki so potrebni za pomembne korake interakcije med entitetami, ki sodelujejo v procesu primera dokazovanja neˇ cesa s samovladno identiteto. V diagramu zaporedja sporoˇ cil na sliki 1 je opisan eden izmed najbolj pogosto predstavljenih primerov interakcij med entitetami, in si- cer tak, kjer se uporablja tudi preverljiva potrdila in je izdajatelj tretja oseba oz. entiteta. Prikazan je scenarij, kjer se uporabnik predstavlja s tr- ditvami tretje osebe, za primer imamo ˇ studenta, ki ˇ studira na neki univerzi. ˇ Student hoˇ ce v knjigarni kupiti knjigo, knjigarna pa za ˇ studente ponuja popust, ki ga ˇ student hoˇ ce izkoristiti. V tem primeru bo moral ˇ student knjigarni dokazati, da je resniˇ cno ˇ student, knjigarna pa to preve- riti, kar bo storil s pomoˇ cjo predstavitve potrdila, ki bo vsebovalo trditev tretje osebe – v tem primeru univerze. ˇ Student predstavlja uporabnika, univerza predstavlja iz- dajatelja, knjigarna pa preverjevalca. Namen diagrama je, da prikaˇ ze, kaj vse naj reˇ sitev omogoˇ ca in s tem tudi funkcionalnosti reˇ sitve. SSI diagram «subjekt» tu e t «subjekt» tu e t «idajatelj» i a «idajatelj» i a «preveritelj» k jigarna «preveritelj» knjigarna veriga_blokov veriga_blokov 1) ustvari in shrani par klju ev (zasebni & javni) 2) usvari DID in DID dokument 3) objavi DID dokument 4) po lje odziv o uspe nosti objave 5) zahteva po potrdilu 6) izda in podpi e potrdilo 7) po lje podpisano potrdilo 8) shrani potrdilo 9) zahteva potrdilo 10) po lje prej pridobljeno potrdilo 11) razre i DID izdajatelja in subjekta vsebovana v potrdilu 12) DID dokumenta subjekta in univerze 13) po lje izziv 14) po lje podpisan izziv 15) preveri ujemanje podpisa potrdila 16) preveri, če je DID izdajatelja na seznamu zaupanja 17) preveri časovno veljavnost potrdila alt [vse se ujema] 18) odobritev potrdila [neujemanje na katerikoli toč ki] 18) zavrnitev potrdila Slika 1: UML diagram zaporedja sporoˇ cil. Na sliki 2 je viden del konˇ cne reˇ sitve. Razdeljena je na pet zavihkov, ki predstavljajo pet glavnih funkcional- nosti potrebnih za potek, prikazan v diagramu na sliki 1. Te so interakcija z datoteko denarnice (uvoz dato- teke, uvoz podatkov datoteko, shranjevanje), ustvarjanje DID-ja ter DID dokumenta in zapis na verigo blokov, ustvarjanje potrdila, preverjanje potrdila (in razreˇ sevanje DID dokumenta z verige blokov s pomoˇ cjo DID-ja) ter sporoˇ canje med uporabniki. Slika 2: Primer datoteke denarnice v konˇ cni reˇ sitvi. 4 Arhitektura reˇ sitve Reˇ sitev je v obliki spletne aplikacije, zato bo uporab- nik na brskalnik za popolno delovanje moral namestiti ˇ se vtiˇ cnik Metamask. Metamask je pri decentraliziranih spletnih aplikacijah, ki uporabljajo verigo blokov, postal 66 nekakˇ sen standarden spletni vtiˇ cnik in veˇ cina spletnih de- centraliziranih aplikacij ga uporablja za povezavo z Ethe- reum vozliˇ sˇ cem. Ker je reˇ sitev spletna aplikacija, pride do problema shranjevanja oziroma deljenja podatkov. Po- datki, kot so javni ter zasebni kljuˇ ci, DID-ji, DID doku- menti, potrdila, so zelo pomembni in praktiˇ cno predsta- vljajo identiteto, zato je bolje, da jih streˇ znik sploh ne vidi. Na tak naˇ cin spletna aplikacija sicer ne deluje kot na- vadna spletna denarnica, ki ponavadi hrani te podatke (si- cer zelo dobro enkriptirane), ampak bolj kot namenska raˇ cunalniˇ ska aplikacija za konˇ cnega uporabnika. Tako bo v tem primeru streˇ znik uporabniku serviral aplikacijo, ki vsebuje kodo, potrebno za vse delovanje, hkrati pa bo po- datke identitete videl samo uporabnik. Ker sem hotel, da bi aplikacija delovala tudi med razliˇ cnimi entitetami na razliˇ cnih raˇ cunalnikih v razliˇ cnih omreˇ zjih, bo streˇ znik v reˇ sitvi odgovoren tudi za poˇ siljanje sporoˇ cil iz ene in- stance aplikacije do druge. To bo sicer pomenilo, da bo streˇ znik videl poslane podatke, a je tak naˇ cin poˇ siljanja sporoˇ cil zgolj namenjen demonstracijskim namenom in se v produkcijskem okolju ne bi uporabljal. Kljub temu pa streˇ znik teh podatkov v reˇ sitvi ne shranjuje. Podatke o uporabnikov identiteti shranjujemo v preprosti .txt da- toteki, v kateri bodo shranjeni vsi podatki, enkriptirana pa bo z geslom s pomoˇ cjo AES enkripcije. Na tak naˇ cin bo uporabnik datoteko lahko preprosto kopiral in ustvaril varnostne kopije, v primeru, da do datoteke pride nekdo drug, pa je ta brez gesla ne bo mogel uporabljati. Uporab- nik bo tako za uporabo reˇ sitve najprej v spletno aplikacijo uvozil datoteko in jo dekriptiral z vnosom gesla. Vsi po- datki datoteke bodo ostali zgolj na uporabnikovi strani in ne bodo ˇ sli na streˇ znik, s podatki bo aplikacija obratovala sama v brskalniku na strani uporabnika. Pomembnejˇ si deli razvoja reˇ sitve so spodaj nekoliko bolj natanˇ cno opisani, veˇ cina ostalih delov reˇ sitve pa sploh ni omenjenih, saj bi sicer razlaga bila preveˇ c obˇ sirna za namen tega ˇ clanka. 4.1 Pametna pogodba Pametna pogodba je program, ki ˇ zivi na Ethereum verigi blokov. Je skupek funkcij in podatkov in je vrsta Ethe- reum raˇ cuna, ki ima lahko doloˇ ceno ˇ stevilo etra (kripto- valuta omreˇ zja Ethereum), lahko tudi kliˇ ce ostale pame- tne pogodbe. Zaˇ zene oziroma kliˇ ce se jo s transakcijo na naslov pametne pogodbe z dodanimi parametri (ˇ ce so ti potrebni). Vse interakcije s pametno pogodbo so ire- verzibilne in pametne podobe z verige blokov ni mogoˇ ce izbrisati, ko je enkrat tja objavljena. Ker reˇ sitev ni namenjena produkcijski rabi, se bo DID in DID-dokumente shranjevalo kar na verigo blokov. Si- cer konceptualno s tem ni niˇ c narobe, a bi se v veˇ cini pro- dukcijskih reˇ sitev zgrajenih na omreˇ zju, kot je na primer Ethereum, to hitro izkazalo kot problematiˇ cno. Sami DID dokumenti bi v produkcijski reˇ sitvi bili veliko veˇ cji, DID dokumentov bi bilo ogromno in poslediˇ cno bi se shranje- vanje tako velikega ˇ stevila podatkov na verigo blokov iz- kazalo kot precej drago, saj veriga blokov ponavadi ni na- menjena shranjevanju ogromne koliˇ cine podatkov (z iz- jemo specializiranih verig blokov). Pri reˇ sitvi bo pametna pogodba odgovorna za zapi- sovanje DID-jev in DID dokumentov na verigo blokov, prav tako bo pametna pogodba odgovorna za razreˇ sevanje DID-jev do DID dokumentov. Kljub temu, da bo konˇ cna pametna pogodba dokaj kratka in preprosta, ta ˇ se vedno igra kljuˇ cno vlogo v celotnem procesu samovladne iden- titete v tej implementaciji. Pametna pogodba vsebuje dve glavni funkciji, eno za dodajanje novega DID-ja ter DID dokumenta na ve- rigo blokov, drugo pa za branje informacij, oziroma ra- zreˇ sevanje DID-ja. DID-ji in DID dokumenti so shranjeni v spremenljivki tipa mapping, ki podatke shranjuje po principu kljuˇ c-vrednost. DID-ji so v tem primeru kljuˇ c, DID dokumenti pa vrednosti. Uspeˇ snost zapisovanja nam pametna pogodba sporoˇ ci preko spremenljivke tipa event, ki je shranjen v dnevniku transakcije. Velja ˇ se omeniti, da je pametna pogodoba objavljena na testnem omreˇ zju Goerli in ne na glavnem Ethereum omreˇ zju. Funkcionalnost reˇ sitve in objava pametne po- godbe bi sicer bili popolnoma enaki, edina razlika bi bila, da bi na pravem Ethereum omreˇ zju za vsak zapis bilo po- trebno plaˇ cati z etri, kar pa za prototipno reˇ sitev predsta- vlja zgolj nepotreben stroˇ sek. 4.2 Datoteka denarnice Ker bo datoteka denarnice preprosta .txt datoteka in ker so ponavadi DID dokumenti ter potrdila predstavljeni v JSON (ang. Javascript Object Notation) formatu, sem se odloˇ cil, da bo tudi sama datoteka denarnice v JSON for- matu. Slika 3: Dekriptirana, prazna datoteka denarnice. Kot videno na sliki 3, je datoteka denarnice zgolj en JSON objekt s tremi vrednostmi, ki so seznami. Prva vrednost je seznam vseh zasebnih kljuˇ cev, druga seznam vseh DID dokumentov, tretja pa seznam vseh potrdil. Ker je potrebno vedeti, kateri zasebni kljuˇ c pripada kateremu DID-ju in poslediˇ cno kateremu DID dokumentu, se oboje v sezname shranjuje na tak naˇ cin, da imata zasebni kljuˇ c ter pripadajoˇ c DID dokument v seznamih enak indeks. 4.3 DID dokument DID dokument je prav tako predstavljen z JSON forma- tom, pirmer pa je viden na sliki 4 Slika 4: Primer DID dokumenta. 67 Znotraj objekta so ˇ stiri vrednosti. Prva vrednost con- text opisuje kontekst DID dokumenta. Tu bi ponavadi bila povezava do opisa strukture DID dokumenta ter for- matov vrednosti v njem in raznorazni opisi standardov, ki bi se potrebovali zato, da lahko naprava razume strukturo DID dokumenta ter ga sprocesira. To je potrebno, ker so med DID dokumenti razliˇ cnih reˇ sitev vedno razlike. Ker ta reˇ sitev ni namenjena za delovanje v produkcijskem okolju in bo moja aplikacija edina, ki bo delovala s ta- kim formatom DID dokumenta, sem v kontekst preprosto samo napisal niz did-dokument, ki oznaˇ cuje, da je to DID dokument. V drugem polju pod kljuˇ cem id imamo DID, ki pripada DID dokumentu in kateri vodi do tega DID do- kumenta. DID je sestavljen iz niza did:dipl: in nato uni- katnega niza DID-ja. Tretje polje vsebuje datum ustvari- tve DID dokumenta, ki je niz v iso8601 formatu. Datum je zgolj informativne narave v tem primeru in ga nebi bilo potrebno vkljuˇ citi za pravilno delovanje DID dokumentu. Na zadnjem mestu je ˇ se najpomembnejˇ si podatek, in si- cer javni kljuˇ c, zapisan kot niz v base64 formatu. Ta javni kljuˇ c pripada DID-ju, do katerega vodi ta dokument, za- sebni kljuˇ c, pripadajoˇ c temu javnemu kljuˇ cu, pa je shra- njen v zgoraj omenjeni tabeli privatniKljuci znotraj dato- teke denarnice. 4.4 Potrdilo Potrdilo ima tri vrednosti, prva je context, ki sluˇ zi istemu namenu kot kontekst v DID dokumentu, le da je tu vre- dnost preprosto “potrdilo”. Pod vrednostjo vsebina pa imamo nov JSON objekt in ta nov objekt vsebuje ˇ sest vre- dnosti. Vsebina je posamezen JSON objekt, da se lahko za podpisovanje preprosto podpiˇ se zgolj objekt in nato podpis uvrsti pod tretjo vrednost podpis. V objektu vse- bina je na prvem mestu vrednost id, ki predstavlja unika- ten id potrdila. Informacija je zgolj informativne narave, sestavljena je iz izraza potr:, ki je preprosto okrajˇ sava za potrdilo, ter unikatnega niza ˇ stevilk, ki predstavlja potr- dilo. Vrednost izdajateljPotrdila vsebuje DID entitete, ki je potrdilo izdala, subjektPotrdila pa DID entitete, na ka- tero se potrdilo nanaˇ sa. datumIzdaje je ravno tako kot datum v DID dokumentu predstavljen kot niz v iso8601 formatu in predstavlja natanˇ cen ˇ cas ter datum, kdaj je bilo potrdilo izdano. V tem primeru datum ni zgolj informa- tiven, temveˇ c sluˇ zi preprostemu preverjanju ˇ casovne ve- ljavnosti potrdila. ˇ Ce je trenutni datum preverjanja po- trdila manjˇ si od datuma izdaje, potem je potrdilo neve- ljavno. Podobno je z vrednostjo datumPoteka, ki pred- stavlja datum poteka potrdila, s katerim lahko preveri- telj enostavno preveri, ˇ ce je trenutni datum preverjanja manjˇ si od datuma poteka, in ˇ ce je to res, potem je potrdilo ˇ se veljavno. Ravno tako kot ostali datumi je to predsta- vljeno z nizom v iso8601 formatu. Zadnja vrednost je ˇ se trditve, ki ravno tako vsebuje JSON objekt. V tem JSON objektu lahko izdajatelj potrdila med ustvaritvijo naniza veˇ c vrednosti, odvisno, za kaj se bo potrdilo uporabljalo in kaj hoˇ ce o subjektu potrdila trditi. V produkcijskem okolju bi trditve bile implementirane drugaˇ ce, a je tak preprostejˇ si naˇ cin zadosten za prikaz delovanja, prav tako je priroˇ cnejˇ si, saj lahko izdajatelj zelo enostavno trdi kar- koli o subjektu potrdila oziroma naniza veˇ c trditev. Slika 5: Primer potrdila oz. poverilnice. 5 Zakljuˇ cek Implementacija naˇ crtovane prototipne reˇ sitve je namenjena laˇ zjemu razumevanju osnovnega tehnoloˇ skega ozadja sis- temov samovladne identitete. S tega staliˇ sˇ ca je namen uspel, saj reˇ sitev omogoˇ ca predvidene osnovne funkcije, ki so pomembne za razumevanje takih sistemov. ˇ Se ve- dno pa ostaja veliko moˇ znih izboljˇ sav. Glede na to, kako je v reˇ sitvi zasnovana denarnica (obratovanje preko .txt datoteke), bi najprimernejˇ sa in najbolj oˇ citna izboljˇ sava bila, da bi reˇ sitev bila implementirana v obliki raˇ cunal- niˇ skega programa ali mobilne aplikacije. Na tak naˇ cin bi reˇ sitev ˇ se bolj ustrezala sploˇ snemu principu, da naj ima uporabnik ˇ cim veˇ c nadzora in da naj bo ˇ cim manj odvi- snosti od centraliziranih tehnologij. Bi pa v tem primeru komuniciranje z Ethereum vozliˇ sˇ ci bilo potrebno izvesti na drugaˇ cen naˇ cin, saj to preko Metamask vtiˇ cnika, ki je namenjen brskalnikom, ne bi bilo veˇ c mogoˇ ce. Zelo pri- merna zboljˇ sava bi bila tudi sprememba sistema poˇ siljanja sporoˇ cil. Trenutno sporoˇ canje poteka s pomoˇ cjo Websoc- ket tehnologije, kjer je seveda streˇ znik vmesni ˇ clen. Tak naˇ cin je za princip samovladne identitete neprimeren. Po- trebno bi bilo implementirati “peer-to-peer” sistem, ki se ponavadi uporablja pri takih sistemih. Moˇ znih izboljˇ sav je seveda ˇ se veˇ c, a kljub temu menimo, da je zastavljeni cilj doseˇ zen. Literatura [1] A. Preukschat in D. Reed, Self-sovereign identity. Manning Publications Co., 2021. [2] Decentralized Identifiers (DIDs) v1.0. spletni naslov: https://www.w3.org/TR/did-core/ (pridobljeno 5. 7. 2022). [3] Verifiable Credentials Data Model v1.1. spletni na- slov:https://www.w3.org/TR/vc-data- model/ (pridobljeno 7. 7. 2022). [4] A. Tobin, “Sovrin: What Goes on the Ledger?”, en, 2018. [5] EBSI Verifiable Credentials Playbook - EBSI Docu- mentation -. spletni naslov:https://ec.europa. eu/digital-building-blocks/wikis/ display/EBSIDOC/EBSI+Verifiable+ Credentials+Playbook (pridobljeno 24. 6. 2022). [6] R. Maruˇ siˇ c, diplomska naloga, Univerza v Ljubljani, Ljubljana, 2022.