did:web objašnjen
Svaki digitalni credential netko je potpisao, a provjeritelj mora moći doznati tko je to i koje ključeve ta strana danas koristi. did:web na to odgovara infrastrukturom koju gotovo svaka organizacija već ima: vlastitim imenom domene. Identifikator kaže koju domenu treba pitati, odgovor je obična datoteka poslužena preko HTTPS-a, i ništa drugo ne mora postojati da bi to radilo.
Što did:web zapravo jest
DID je trajan identifikator koji svatko može potražiti kako bi pronašao javne ključeve onoga tko ga drži. DID metoda je pravilo za to traženje, a ima ih na desetke. Jedne zapisuju zapis u blockchain, druge u mrežu izgrađenu baš u tu svrhu, i svaka prisiljava provjeritelja da nauči kako radi upravo taj sustav.
did:web ide suprotnim putem. Traženje je HTTPS zahtjev prema domeni navedenoj u identifikatoru, a zapis je JSON datoteka koju vlasnik domene objavljuje i uređuje kao bilo koju drugu stranicu svoga web-mjesta. Nema mreže kojoj se treba pridružiti, knjige u koju treba pisati ni naknade koju treba platiti.
Zato se pojavljuje tako rano u gotovo svakom projektu. Tim koji zna postaviti datoteku na svoj web poslužitelj može izdavati i provjeravati credentiale već to isto poslijepodne, a identifikator koji dobije pravi je DID koji prihvaća svaki usklađeni novčanik ili provjeritelj, a ne privremeno rješenje za kasniju zamjenu.
Kako identifikator postaje URL
Preslikavanje je mehaničko i u tome je cijela poanta. Gola domena vodi do datoteke u well-known direktoriju koji web-mjesta već koriste za strojno čitljive metapodatke. Dodate li iza domene dijelove odvojene dvotočkama, oni postaju dijelovi putanje, pa jedna organizacija može objaviti zaseban identifikator po odjelu, po okruženju ili po usluzi izdavanja bez registriranja ičega novog.
Dvije pojedinosti lako promaknu. Kod broja porta dvotočku treba kodirati postotkom jer obična dvotočka već razdvaja dijelove identifikatora. A datoteka mora biti poslužena preko HTTPS-a s certifikatom koji se provjerava, budući da je prijenos jedino što stoji između provjeritelja i krivotvorenog odgovora.
Identifikator koji vam netko da
did:web:example.com:issuer:euHTTPS adresa na koju se preslikava, bez usluge pretraživanja između
https://example.com/issuer/eu/did.jsonVraćeni DID document s ključevima i krajnjim točkama
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Zašto ga organizacije biraju
Prvi je razlog prepoznatljivost. Provjeritelj koji vidi identifikator usmjeren na domenu tvrtke može na najjednostavniji mogući način provjeriti da ime na credentialu odgovara imenu na web-mjestu. Nikome ne treba prethodno objašnjavati upit u registar ni lanac certifikata da bi to sjelo.
Drugi je da rad ne košta ništa. Dokument stoji iza istog hostinga, istog nadzora i istog procesa promjena kao i ostatak web-mjesta. Nema zasebnog sustava koji bi trebalo financirati, održavati dostupnim ili objašnjavati revizoru, a rotacija ključa je isporuka, a ne transakcija.
Treći je prenosivost. Budući da je podržava svaka biblioteka novčanika i provjeritelja, did:web je metoda koja će najvjerojatnije proraditi s partnerom s kojim se nikada niste integrirali, što je čini prirodnim izborom za pilote, testna okruženja i one događaje o interoperabilnosti na kojima se susreću europske izvedbe novčanika.
Gdje did:web prestaje
Sve što metoda daje počiva na domeni. Tko nadzire registraciju, poslužitelje imena i certifikat, nadzire i identifikator, pa je isteklo produženje, otet DNS račun ili pogrešno izdan certifikat dovoljno da netko govori u vaše ime. Ispod toga nema drugog potpisa na koji bi se moglo osloniti.
Nema ni pamćenja. Provjeritelj vidi dokument onakav kakav je upravo sada i nema načina doznati što je u njemu pisalo prošli tjedan, pa se zamijenjeni ključ ne može razlikovati od rotiranog. did:webvh postoji upravo zbog toga: isti web hosting, uz potpisan zapisnik svake promjene u koji se može samo dodavati, tako da provjeritelj može pratiti povijest od prvog unosa do trenutnog stanja.
I to nije provjera identiteta. Objava dokumenta pod domenom dokazuje nadzor nad tom domenom i ništa više. Kada provjeritelj mora znati da je pravna osoba ona za koju se izdaje, ta sigurnost dolazi iz Trusted List, kvalificiranog certifikata ili Trust Framework izgrađenog u tu svrhu, dok DID metoda nosi samo ključeve ispod.
Što to znači za vas
Izdavatelj
Prema dokumentu se od prvog dana odnosite kao prema produkcijskoj infrastrukturi. Stavite ga pod kontrolu promjena, nadzirite odgovara li adresa i vrijedi li certifikat, i ostavite povučeni ključ na popisu za provjeru sve dok je u uporabi išta što je njime potpisano.
Pouzdana strana
Dohvatiti dokument nije isto što i vjerovati mu. Zasebno odlučite koje domene prihvaćate, odbijte sve čiji se certifikat ne provjerava i predmemorirajte pažljivo: zastarjela kopija održava opozvani ključ na životu, a kopija koje nema ruši vašu uslugu zajedno s onom druge strane.
Imatelj novčanika
Domena u identifikatoru izdavatelja vrijedi pogleda. To je jedini dio credentiala koji možete pročitati bez ikakvih alata, a ime koje ne odgovara očekivanoj organizaciji razlog je da stanete, a ne da nastavite.
Povezani pojmovi
Često postavljana pitanja
Treba li mi poseban softver za razrješavanje did:web identifikatora?
Ne. Identifikator je recept za sastavljanje URL-a, a dohvaćanje te adrese preko HTTPS-a vraća dokument. To može bilo koji HTTP klijent i upravo je zato did:web obično prva metoda koju tim pokrene. Opću biblioteku za razrješavanje ipak se isplati koristiti u produkciji jer jednoobrazno primjenjuje pravila kodiranja i provjere dokumenta umjesto da ih prepusti svakom pozivatelju.
Je li did:web manje pouzdan jer nema blockchaina?
Pouzdan je na drugi način. Metoda koja se oslanja na raspodijeljenu knjigu razlaže zapis na mnogo strana, tako da ga nijedna ne može tiho prepisati. did:web tu odgovornost stavlja na vlasnika domene i na ovjerovitelje iza njegova TLS-a. Za organizaciju čije su ime i web-mjesto već ono što kupci prepoznaju, to je često najpošteniji smještaj za takvo povjerenje, dokle god svi razumiju da je domena slaba točka.
Što se događa s već izdanim credentialima kada se ključevi promijene?
Provjeritelj dohvaća dokument onakav kakav je sada, pa se credential potpisan ključem koji je u međuvremenu uklonjen više ne provjerava. Zadržite povučeni ključ u dokumentu, označen tako da može provjeravati, ali više ne potpisivati, barem onoliko dugo koliko vrijede credentiali koje je potpisao. Ako provjeritelj mora moći dokazati koji je ključ vrijedio na određeni datum, upravo tu did:webvh zaslužuje svoju dodatnu složenost.
Izvori
Ova je stranica informativna i ne predstavlja pravni savjet. Za mjerodavne smjernice pogledajte izravno specifikacije W3C-a.