did:web paaiškintas
Kiekvieną skaitmeninį credential kažkas pasirašė, ir tikrintojas turi galėti sužinoti, kas tai ir kokius raktus jis naudoja šiandien. did:web į tai atsako infrastruktūra, kurią beveik kiekviena organizacija jau turi: savo domeno vardu. Identifikatorius nurodo, kurio domeno klausti, atsakymas yra įprastas failas, pateikiamas per HTTPS, ir nieko daugiau nereikia, kad tai veiktų.
Kas iš tikrųjų yra did:web
DID yra nuolatinis identifikatorius, kurį bet kas gali susirasti, kad rastų jį turinčiojo viešuosius raktus. DID metodas yra tos paieškos taisyklė, ir tokių yra dešimtys. Vieni įrašą rašo į blokų grandinę, kiti į tam sukurtą tinklą, ir kiekvienas verčia tikrintoją išmokti, kaip veikia būtent ta sistema.
did:web eina priešinga kryptimi. Paieška yra HTTPS užklausa identifikatoriuje nurodytam domenui, o įrašas yra JSON failas, kurį domeno savininkas paskelbia ir redaguoja kaip bet kurį kitą savo svetainės puslapį. Nėra tinklo, prie kurio reikėtų prisijungti, didžiosios knygos, į kurią reikėtų rašyti, nei mokesčio, kurį reikėtų mokėti.
Todėl jis taip anksti iškyla beveik kiekviename projekte. Komanda, mokanti įkelti failą į savo interneto serverį, gali išduoti ir tikrinti credentials tą pačią popietę, o gautas identifikatorius yra tikras DID, kurį priima kiekviena reikalavimus atitinkanti piniginė ar tikrintojas, o ne laikinas sprendimas, kurį vėliau reikės pakeisti.
Kaip identifikatorius tampa URL adresu
Atvaizdavimas yra mechaninis, ir būtent tai yra esmė. Plikas domenas veda į failą well-known kataloge, kurį svetainės jau naudoja mašininiu būdu skaitomiems metaduomenims. Pridėjus po domeno dvitaškiais atskirtas dalis, jos tampa kelio dalimis, todėl viena organizacija gali paskelbti atskirą identifikatorių kiekvienam padaliniui, aplinkai ar išdavimo paslaugai, nieko naujo neregistruodama.
Dvi smulkmenos dažnai praslysta. Prievado numerio dvitaškį reikia užkoduoti procentais, nes paprastas dvitaškis jau skiria identifikatoriaus dalis. O failas turi būti pateikiamas per HTTPS su sertifikatu, kuris patvirtinamas, nes perdavimas yra vienintelis dalykas tarp tikrintojo ir suklastoto atsakymo.
Identifikatorius, kurį kas nors jums pateikia
did:web:example.com:issuer:euHTTPS adresas, į kurį jis atvaizduojamas, be jokios paieškos tarnybos tarpe
https://example.com/issuer/eu/did.jsonGrąžinamas DID document su raktais ir galiniais taškais
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Kodėl organizacijos jį renkasi
Pirmoji priežastis yra atpažįstamumas. Tikrintojas, matantis identifikatorių, rodantį į įmonės domeną, gali paprasčiausiu įmanomu būdu patikrinti, kad vardas ant credential sutampa su vardu svetainėje. Niekam nereikia pirma aiškinti registro užklausos ar sertifikatų grandinės, kad tai būtų suprasta.
Antroji yra ta, kad eksploatuoti nieko nekainuoja. Dokumentas yra už to paties prieglobos, tos pačios stebėsenos ir to paties pokyčių proceso kaip ir likusi svetainė. Nėra atskiros sistemos, kurią reikėtų finansuoti, laikyti prieinamą ar aiškinti auditoriui, o rakto keitimas yra diegimas, o ne sandoris.
Trečioji yra perkeliamumas. Kadangi jį palaiko kiekviena piniginės ir tikrintojo biblioteka, did:web yra metodas, kuris labiausiai tikėtina suveiks su partneriu, su kuriuo niekada nesate integravęsi. Dėl to jis natūraliai tinka bandomiesiems projektams, testinėms aplinkoms ir toms sąveikumo renginiams, kur susitinka Europos piniginių įgyvendinimai.
Kur did:web sustoja
Viskas, ką metodas duoda, remiasi domenu. Kas valdo registraciją, vardų serverius ir sertifikatą, tas valdo identifikatorių, todėl pasibaigęs pratęsimas, užgrobta DNS paskyra ar klaidingai išduotas sertifikatas pakanka, kad kas nors kalbėtų jūsų vardu. Apačioje nėra antro parašo, kuriuo būtų galima remtis.
Jis taip pat neturi atminties. Tikrintojas mato dokumentą tokį, koks jis yra šią akimirką, ir neturi kaip sužinoti, kas jame buvo praėjusią savaitę, todėl pakeisto rakto neįmanoma atskirti nuo pakeisto pagal tvarką. did:webvh egzistuoja būtent tam: ta pati interneto prieglauda plius pasirašytas kiekvieno pakeitimo žurnalas, prie kurio galima tik pridėti, kad tikrintojas galėtų sekti istoriją nuo pirmojo įrašo iki dabartinės būsenos.
Ir tai nėra tapatybės patikra. Dokumento paskelbimas po domenu įrodo to domeno valdymą ir nieko daugiau. Kai tikrintojui reikia žinoti, kad juridinis asmuo yra tas, kuo sakosi esąs, tas tikrumas ateina iš Trusted List, kvalifikuoto sertifikato arba tam sukurto Trust Framework, o DID metodas tik neša po jais esančius raktus.
Ką tai reiškia jums
Išdavėjas
Elkitės su dokumentu kaip su gamybine infrastruktūra nuo pirmos dienos. Įtraukite jį į pokyčių valdymą, stebėkite, ar adresas atsako ir ar sertifikatas galioja, ir palikite pašalintą raktą sąraše tikrinimui tol, kol kas nors juo pasirašyta dar naudojama.
Pasitikinti šalis
Parsisiųsti dokumentą nėra tas pat, kas juo pasitikėti. Atskirai nuspręskite, kuriuos domenus priimate, atmeskite viską, kurio sertifikatas nepatvirtinamas, ir talpyklą naudokite atsargiai: pasenusi kopija palaiko atšauktą raktą gyvą, o trūkstama parklupdo jūsų paslaugą kartu su kitos pusės.
Piniginės turėtojas
Domenas išdavėjo identifikatoriuje vertas žvilgsnio. Tai vienintelė credential dalis, kurią galite perskaityti be jokių įrankių, o vardas, neatitinkantis tikėtos organizacijos, yra priežastis sustoti, o ne tęsti.
Susiję terminai
Dažnai užduodami klausimai
Ar did:web identifikatoriui išspręsti reikia specialios programinės įrangos?
Ne. Identifikatorius yra receptas URL adresui sudaryti, o parsisiuntus tą adresą per HTTPS gaunamas dokumentas. Tai gali padaryti bet kuris HTTP klientas, todėl did:web paprastai yra pirmasis metodas, kurį komanda paleidžia. Bendrosios sprendimo bibliotekos gamyboje vis tiek verta naudoti, nes ji vienodai taiko kodavimo taisykles ir dokumento patikras, užuot palikusi jas kiekvienam kviečiančiajam.
Ar did:web mažiau patikimas, nes nėra blokų grandinės?
Jis patikimas kitaip. Paskirstyta didžiąja knyga grįstas metodas išskaido įrašą tarp daugelio šalių, kad nė viena negalėtų jo tyliai perrašyti. did:web šią atsakomybę uždeda domeno savininkui ir sertifikavimo įstaigoms už jo TLS. Organizacijai, kurios pavadinimą ir svetainę klientai ir taip atpažįsta, tai dažnai sąžiningiausia vieta pasitikėjimui, kol visi supranta, kad domenas yra silpnoji vieta.
Kas nutinka jau išduotiems credentials, kai raktai pasikeičia?
Tikrintojas parsisiunčia dokumentą tokį, koks jis yra dabar, todėl credential, pasirašytas nuo tada pašalintu raktu, nebepatvirtinamas. Palikite pašalintą raktą dokumente, pažymėtą taip, kad jis galėtų tikrinti, bet nebepasirašyti, bent tol, kol galioja juo pasirašyti credentials. Jei tikrintojui reikia įrodyti, kuris raktas galiojo tam tikrą dieną, būtent ten did:webvh pateisina savo papildomą sudėtingumą.
Šaltiniai
Šis puslapis yra informacinio pobūdžio ir nėra teisinė konsultacija. Dėl autoritetingų nurodymų kreipkitės tiesiai į W3C specifikacijas.