did:web selitettynä
Jokaisen digitaalisen credentialin on allekirjoittanut joku, ja todentajan on pystyttävä selvittämään, kuka se on ja mitä avaimia tämä käyttää tänään. did:web vastaa tähän sillä infrastruktuurilla, joka lähes jokaisella organisaatiolla jo on: sen omalla verkkotunnuksella. Tunniste kertoo, miltä verkkotunnukselta kysytään, vastaus on tavallinen HTTPS:n yli tarjoiltu tiedosto, eikä mitään muuta tarvitse olla olemassa, jotta se toimii.
Mikä did:web oikeastaan on
DID on pysyvä tunniste, jonka avulla kuka tahansa voi etsiä sen haltijan julkiset avaimet. DID-menetelmä on sääntö, joka kuvaa tuon haun, ja niitä on kymmeniä. Osa kirjoittaa merkinnän lohkoketjuun, osa sitä varten rakennettuun verkkoon, ja jokainen pakottaa todentajan opettelemaan, miten juuri se järjestelmä toimii.
did:web kulkee päinvastaiseen suuntaan. Haku on HTTPS-pyyntö tunnisteessa mainittuun verkkotunnukseen, ja merkintä on JSON-tiedosto, jonka verkkotunnuksen omistaja julkaisee ja muokkaa kuten minkä tahansa muun sivun sivustollaan. Ei ole verkkoa johon liittyä, ei kirjanpitoa johon kirjoittaa eikä maksua suoritettavaksi.
Siksi se tulee vastaan niin varhain lähes jokaisessa hankkeessa. Tiimi, joka osaa viedä tiedoston verkkopalvelimelleen, voi myöntää ja todentaa credentialeja jo samana iltapäivänä, ja saatu tunniste on aito DID, jonka mikä tahansa standardinmukainen lompakko tai todentaja hyväksyy, ei väliaikainen ratkaisu myöhemmin korvattavaksi.
Miten tunnisteesta tulee URL
Kuvaus on mekaaninen, ja juuri siinä on sen pointti. Pelkkä verkkotunnus johtaa tiedostoon siinä well-known-hakemistossa, jota sivustot jo käyttävät koneluettavaan metatietoon. Kun verkkotunnuksen perään lisätään kaksoispistein erotettuja osia, niistä tulee polkuosia, joten yksi organisaatio voi julkaista erillisen tunnisteen osastoa, ympäristöä tai myöntämispalvelua kohden rekisteröimättä mitään uutta.
Kaksi yksityiskohtaa jää helposti huomaamatta. Porttinumeron kaksoispiste on koodattava prosenttimerkinnällä, koska pelkkä kaksoispiste erottaa jo tunnisteen osat toisistaan. Ja tiedosto on tarjoiltava HTTPS:n yli varmenteella, joka kelpaa, sillä siirtotie on ainoa asia todentajan ja väärennetyn vastauksen välissä.
Tunniste, jonka joku antaa sinulle
did:web:example.com:issuer:euHTTPS-URL, johon se kuvautuu, ilman välissä olevaa hakupalvelua
https://example.com/issuer/eu/did.jsonPalautuva DID document, joka sisältää avaimet ja päätepisteet
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Miksi organisaatiot valitsevat sen
Ensimmäinen syy on tunnistettavuus. Todentaja, joka näkee yrityksen verkkotunnukseen osoittavan tunnisteen, voi tarkistaa kaikkein yksinkertaisimmalla tavalla, että credentialissa oleva nimi vastaa verkkosivuston nimeä. Kenellekään ei tarvitse selittää rekisterihakua tai varmenneketjua ennen kuin asia menee perille.
Toinen on se, ettei sen ylläpito maksa mitään. Dokumentti on saman webhotellin, saman valvonnan ja saman muutosprosessin takana kuin muukin sivusto. Ei ole erillistä järjestelmää rahoitettavaksi, saatavilla pidettäväksi tai tilintarkastajalle selitettäväksi, ja avaimen kierrätys on julkaisu eikä tapahtuma.
Kolmas on siirrettävyys. Koska jokainen lompakko- ja todentajakirjasto tukee sitä, did:web on menetelmä, joka todennäköisimmin toimii sellaisen kumppanin kanssa, jonka kanssa et ole koskaan integroinut. Se tekee siitä luontevan valinnan pilotteihin, testiympäristöihin ja niihin yhteentoimivuustapahtumiin, joissa eurooppalaiset lompakkototeutukset kohtaavat.
Mihin did:web loppuu
Kaikki, mitä menetelmä antaa, lepää verkkotunnuksen varassa. Se, joka hallitsee rekisteröintiä, nimipalvelimia ja varmennetta, hallitsee tunnistetta, joten vanhentunut uusiminen, kaapattu DNS-tili tai virheellisesti myönnetty varmenne riittää puhumaan sinun nimissäsi. Alla ei ole toista allekirjoitusta, johon turvautua.
Sillä ei myöskään ole muistia. Todentaja näkee dokumentin sellaisena kuin se juuri nyt on eikä voi mitenkään saada selville, mitä siinä luki viime viikolla, joten vaihdettua avainta ei voi erottaa kierrätetystä. did:webvh on olemassa juuri tätä varten: sama webhotelli sekä allekirjoitettu, vain lisäyksiä salliva loki jokaisesta muutoksesta, jotta todentaja voi seurata historiaa ensimmäisestä merkinnästä nykytilaan.
Eikä se ole henkilöllisyyden tarkistus. Dokumentin julkaiseminen verkkotunnuksen alla todistaa hallinnan tuohon verkkotunnukseen eikä mitään muuta. Kun todentajan on tiedettävä, että oikeushenkilö on se, joka väittää olevansa, varmuus tulee luotettujen luettelosta, hyväksytystä varmenteesta tai tätä varten rakennetusta luottamuskehikosta, ja DID-menetelmä kantaa vain avaimet niiden alla.
Mitä tämä tarkoittaa sinulle
Myöntäjä
Kohtele dokumenttia tuotantoinfrastruktuurina ensimmäisestä päivästä alkaen. Ota se muutoshallinnan piiriin, valvo että URL vastaa ja että varmenne on voimassa, ja pidä poistettu avain listattuna todentamista varten niin kauan kuin jokin sillä allekirjoitettu on vielä käytössä.
Luottava osapuoli
Dokumentin hakeminen ei ole sama asia kuin siihen luottaminen. Päätä erikseen, mitkä verkkotunnukset hyväksyt, hylkää kaikki, joiden varmenne ei kelpaa, ja käytä välimuistia harkiten: vanhentunut kopio pitää peruutetun avaimen hengissä, ja puuttuva kaataa palvelusi yhdessä vastapuolen kanssa.
Walletin haltija
Myöntäjän tunnisteessa oleva verkkotunnus kannattaa vilkaista. Se on credentialin ainoa osa, jonka voit lukea ilman työkaluja, ja nimi, joka ei vastaa odottamaasi organisaatiota, on syy pysähtyä eikä jatkaa.
Aiheeseen liittyvät termit
Usein kysytyt kysymykset
Tarvitsenko erityistä ohjelmistoa did:web-tunnisteen selvittämiseen?
Et. Tunniste on ohje URL-osoitteen rakentamiseen, ja kun tuon osoitteen hakee HTTPS:llä, vastaukseksi tulee dokumentti. Mikä tahansa HTTP-asiakas pystyy siihen, ja siksi did:web on yleensä ensimmäinen menetelmä, jonka tiimi saa toimimaan. Yleiskäyttöinen resolver-kirjasto kannattaa silti ottaa tuotantoon, koska se soveltaa koodaussäännöt ja dokumentin tarkistukset johdonmukaisesti sen sijaan, että jättäisi ne jokaisen kutsujan vastuulle.
Onko did:web vähemmän luotettava, koska lohkoketjua ei ole?
Se on luotettava eri tavalla. Hajautettuun kirjanpitoon perustuva menetelmä jakaa merkinnän monen osapuolen kesken, jottei yksikään voisi kirjoittaa sitä hiljaa uusiksi. did:web asettaa vastuun verkkotunnuksen omistajalle ja niille varmentajille, jotka ovat sen TLS:n takana. Organisaatiolle, jonka nimi ja verkkosivusto ovat jo se, minkä asiakkaat tunnistavat, tämä on usein rehellisin paikka luottamukselle, kunhan kaikki ymmärtävät verkkotunnuksen olevan heikko kohta.
Mitä tapahtuu jo myönnetyille credentialeille, kun avaimet vaihtuvat?
Todentaja hakee dokumentin sellaisena kuin se nyt on, joten credential, joka on allekirjoitettu sittemmin poistetulla avaimella, ei enää todennu. Pidä poistettu avain dokumentissa merkittynä niin, että se voi todentaa mutta ei enää allekirjoittaa, vähintään niin kauan kuin sillä allekirjoitetut credentialit ovat voimassa. Jos todentajan on pystyttävä osoittamaan, mikä avain oli voimassa tiettynä päivänä, siinä kohdassa did:webvh ansaitsee lisämonimutkaisuutensa.
Lähteet
Tämä sivu on tiedoksi eikä ole oikeudellinen neuvo. Sitovaa ohjausta varten tutustu suoraan W3C:n spesifikaatioihin.