Uudised, sündmused ja blogi

Siit leiad kõik meie uudised, blogipostitused ja ürituste, hoolduste ja katkestuste informatsiooni.

Tagasi

ID4me - tugeva isikutuvastusega?

Teine kohtumine ID4me (DNS-põhine SSO ehk single sign-on teenus) töögrupi kohtumine toimus Frankfurdis Saksa .de tippdomeeniregistri (Denic) kontoris. Eelmisest kohtumisest oli juttu siin.
ID4me - tugeva isikutuvastusega?

Minu eesmärk selles töögrupis on suunata asju lihtsast SSO teenusest, mis konkureerib Google ja Facebookiga, tugevalt tuvastatud identiteetide kasutamise suunas. Hea meel on, et esimesed viljad juba paistavad. Pelgalt SSO teenusest ei olnud seekord peaaegu juttugi. Isegi nii palju, et Denici teenuste müügijuhi esitluse peale küsis Denici arendusjuht, et miks SSOd isegi ei mainitud esitluses. Kindlasti on aga vara veel eeldada, et siit tuleb lahendus, mille abil saame oluliselt leevendada oma välismaiste registreerijate tuvastamise probleemi.

Et tugev isikutuvastus on laual täiendava lisaväärtust pakkuva võimalusena, seisab projekti meeskond vastamisi uute probleemidega. Tuvastamise tasemete sisseviimine ökosüsteemi tõstab oluliselt keerukust. Avatud ja ühtsest süsteemist on sellega saanud erinevatest saarekestest koosnev ökosüsteem, kus lõppkasutaja, kellel on “taskus” ID4me konto, ei saa olla kindel, et saab kasutada kõiki ID4me toega teenuseid, sest tema isik pole konto saamisel piisavalt tugevasti tuvastatud. Kuidas üldse veenduda kui tugevalt kasutaja on tuvastatud? Ning, kuidas saame kindlad olla, et identiteedi agentide, kelle valduses on isikuandmed, väited identiteedi tuvastatuse taseme kohta saab usaldada?

Oletame, et meie .ee registrina, otsustame vastu võtta vaid enda juures tuvastatud kasutajaid (sest pole teisi agente, kes pakuks piisavalt kõrge tuvastatuse tasemega identiteete). Kuidas kommunikeerida seda kasutajale, et ei tekiks olukorda, kus kasutaja saab alles autentimise protsessi lõpus teada, et tema konto ei sobi. Üks võimalus on kasutada erinevat nuppu, brändi või tunnust. “.ee ID4me” kasutajad saavad kasutada kõiki id4me ökosüsteemi teenuseid, aga vaid .ee juures tuvastatud saavad kasutada seda kontot .ee registreerimiseks. Kui nüüd soovime lubada ka Taani registris kontrollitud isikuid… Parem oleks kasutada ühtset tähistust nagu ID4me+ aga tasemeid on ilmselt eIDASi eeskujul 3 või 4 (ISO 29115 vs EIDAS). Ilmselt ei kao ka huvi tekitada agendipõhiseid piiranguid, mis kõik teeb lõppkasutaja jaoks pildi väga segaseks.

Isikutuvastuse tasemete eristamine pole ainus muutus, mis vahepeal on toimunud. Ka rollide lahusus pole enam kivisse raiutud. Meenutuseks oli projekti üks lähteideedest rangelt lahutatud identiteedi hoidja ja agendi rollid - üks on siis see, kelle valduses on isikuandmed ja teine see, kelle valduses on kasutaja tunnused ja salasõnad. Saksa register tegelebki nüüd kaht rolli ühendava lahenduse kallal. Kui küsida, mille poolest ID4me erineb pärast seda FB või Google SSO lahendustest, siis ongi vastus kasutajaandmete kontroll.

Uue huvitava mõttena ID4me väärtuspakkumise kohapealt on võimalus lõppkasutajal kontrollida kaupmehe usaldusväärsust enne kui oma andmeid kaupmehega jagada. Teisalt tekitab see barjääri, mille kaupmees peab ületama enne kui üldse saab hakata ID4me kontosid aktsepteerima, mis aga ei aita kindlasti teenuse levikule kaasa.

Veel lahendamist vajavaid küsimusi: Kuidas toimub isikuandmeid hoidva identiteedi agendi vahetus? Agent peab omama ligipääsu ja kontrolli identiteediga seotud domeeni DNS andmetele - kas agent peab siis olema peamine domeeni tehniline kontakt ja omama kontrolli kõigi domeeniga seotud nimeserverite üle? Kuidas kontrollida, et agendid järgivad ette antud standardit (protsessi) eeldusel, et selline on üldse paigas? Missugune on osapoolte vastutus, kui nende hoolimatuse tõttu andmed lekivad või kasutaja saab võimekuse esitleda ennast kellegi teisena? Kas on ka võimalus identiteet blokeerida kui kasutaja või agent näiteks saab teada, et konto on kompromiteeritud? Iga identiteediga võib olla seotud mitmeid identifikaatoreid seega kuidas toimub kasutaja konto kontrollimisek vajaliku identiteedi hoidja leidmine.

Viimase küsimuse kallal käib kibe töö - vaatluse all kaks varianti IDP (identity provider) leidmine registripidaja toest sõltuma (rfc5074 domain look a side validation sarnane lahendus). Teine võimalus on alt üles otsing (bottom-up discovery), kus pöördutakse tase kõrgemal oleva domeeni poole, kui vastaval tasemel puudub vajalik kirje.

Töö jätkub...

Kommentaarid

Email again:

Veel uudiseid, sündmusi ja blogipostitusi