Tänne sivulle koostetaan webinaareissa esitettyjä kysymyksiä ja vastauksia.

Yleiset

Kuinka helppoa on tulla osaksi EUDI-wallet ekosysteemiä? 
Valmistelutyössä pyritään siihen, että liittyminen on helppoa ja ekosysteemistä tulisi elinvoimainen.

Kuinka pitkiä siirtymäajat ovat keskimäärin eIDAS-asetuksen hyväksymisen jälkeen?

Uudistettu eIDAS-asetus on tullut voimaan 20.5 ja sitä koskevat tekniset täytäntöönpanosäädökset annetaan seuraavien kuuden kuukauden kuluessa. Näiden täytäntöönpanosäädösten  hyväksymisen jälkeen jäsenvaltioilla on kaksi vuotta (24kk) aikaa tarjota Eurooppalaisen digitaalisen identiteetin lompakko (EUDI-lompakko) kansalaisten käyttöön, eli arviolta vuoden 2026 lopussa.

Kysymys liittyen lompakkoekosysteemiin; tavoitteleeko sääntely mallia jossa on valinnanvaraa lompakoiden osalta vai mallia, jossa käyttäjällä ei valinnanvaraa? Ja onko Suomen tahotilaa tämän osalta jo määritetty? 

Tavoitteena ennemmin valinnanvaraa mahdollistavat lompakot. Vastaus kokonaisuudessaan tallenteelta 10.11.23.

Onko tiedossa jo aikataulu Suomen lainsäädäntömuutoksista?

Aikataulun osalta viimeinen takaraja tulee eIDAS-asetuksesta. Valtiovarainministeriö on asettanut uudistetun eIDAS-asetuksen kansallisen täytäntöönpanon hankkeen ja uudistetun eIDAS-asetuksen kansallisen täytäntöönpanon lainsäädäntötyöryhmän. Valtiovarainministeriö tiedottaa työryhmien asioista erikseen. Mahdolliset tiedotteet jaetaan myös DVV:n viestintäkanavissa.

Lompakkosovellusten lähdekoodin avoimuudesta kysyttiin. Komissio valmistelee referenssitoteutusta, joka julkaistaan avoimena koodina mutta entä sitten varsinaisten lompakoiden lähdekoodi?

Ehdotus tuli asetukseen parlamentin kautta ja asetus ottaa lähtökohdaksi avoimen lähdekoodin. Tähän liittyy kansallista liikkumavaraa. Suomessa tullaan kansallisen täytäntöönpanon osalta keskustelemaan. Vastaus kokonaisuudessaan tallenteelta 10.11.23.

Nyt kun asetuksesta on päästy sopuun, alkaa täytäntöönpanoasetusten valmistelu. Toolbox-työllä vaikutetaan niiden sisältöön. Kysyttiin, että miten Suomi vaikuttaa tähän?

Toolbox-työ antaa konkreettisia syötteitä sekä teknisen toteutuksen että arkkitehtuurin näkökulmasta. Tämän osalta olemme olleet aktiivisia, ja useita eri toimijoita on mukana. Vastaus kokonaisuudessaan tallenteelta 10.11.23.

Viime viikosta alkaen on ollut jonkin verran julkista keskustelua liittyen juurivarmenteisiin ja siihen, että asetuksen myötä selaimille tulisi velvollisuus hyväksyä jokaisen jäsenvaltion varmenne. Tässä on nähty uhkia liittyen siihen, että voisi mahdollistaa selainliikenteen seuraamisen. Miten kommentoitte asiaa?

Valtiovarainministeriön vastaus: Asetus ja sen täytäntöönpanosäädökset, vaatimuksenmukaisuuden arviointikriteerit tulevat tarjoamaan tekniset kontrollit, eli ei ole pelkästään hallinnollisia kontrolleja. Valmistelua on lisäksi tehty useiden vuosien ajan. Vastine tähän löytyy: https://www.european-signature-dialog.eu/ESD_answer_to_Mozilla_misinformation_campaign.pdf Vastaus kokonaisuudessaan tallenteelta 10.11.23.

Muutama kysymys esitettiin liittyen lompakon käyttöönottoon ja siihen, tapahtuuko se hyödyntäen henkilökorttia tai passia NFC:n avulla etälukemalla. Lisäksi kysyttiin, mistä kasvokuva lompakkosovellukseen tulee. 

Käyttöönoton toteutuksen osalta ei varmuutta vielä ole. Käyttöönoton täytyy täyttää korkeimman varmuustason vaatimukset. Toivottavasti pystymme mahdollistamaan sen, että suomalaiset voisivat saada lompakon etänä käyttöön. Kasvokuvaan liittyviä linjauksia ei ole vielä tehty. Kansallisen ja EU-säätelyn kautta tähän saadaan vastauksia. Vastaus kokonaisuudessaan tallenteelta 10.11.23.

 Miten tulevaisuudessa lukijasovelluksen käyttö yksityishenkilölle esim. yksityishenkilöiden välisessä autokaupassa.

Sääntely on vielä kesken tämän osalta, mutta eIDAS-sääntelystä johdettuna lompakosta lompakkoon lukeminen  voisi tulla kyseeseen. Toiminnallisuuksien osalta tulemme saamaan tarkempia tietoja ja vaatimuksia uudistuneen eIDAS-asetuksen toimeenpanomääritysten kautta. 

Onko käytettävyyttä vielä päästy testaamaan käytännössä? Onko harkittu NFC-yhteyden käyttöä Bluetoothin sijaan, nyt kun se on vapautumassa myös Applen alustoilla? 

Käytettävyystestejä esimerkkisovelluksella on jo tehty osana tiimin jatkuvaa kehitystyötä ja tätä ollaan edelleen jatkamassa. Vaikka Apple on EU:n alueella vapauttamassa NFC:n käyttöä, sitä ei ole toistaiseksi lähdetty edistämään esimerkkisovelluksen kehityksessä. NFC:n käyttö soveltuu erityisesti hyvin sellaisiin käyttötapauksiin, joissa etukäteen tiedetään mitä tietoja ollaan jakamassa ja toistaiseksi demosovelluksessa ei olla vielä lähdetty toteuttamaan sellaisia käyttötapauksia.

Identity matchingiin liittyen: riittääkö suomalaisesta näkökulmasta vaaditut 4/6 attribuuttia luotettavaan linkitykseen?

Vaaditut attribuutit ovat melko hyvin linjassa aiemman KEHA-keskuksen linkitykseen liittyvien havaintojen / ehdotusten kanssa. Ongelma on kuitenkin tässä vaiheessa tunnisteen (unique_id / personidentifier) puuttuminen PID-vaatimuksista.. 

Tekniset

Missä mittaluokassa mobiililaitteiden "secure element" tallennustila liikkuu? Paljonko tilaa vie piloteissa esiintyvät todisteet? Eli onko fyysisten rajoitteiden puitteissa ylipäätään realistista ajatella lompakossa kaiken ao. datan tallettamista turvattuun muistiin?

Mobiililaitteen secure elementin vastuulla on ensisijaisesti kryptografisten avainten hallinta, ei varsinainen kredentiaalidata. Huomioitavaa, että ARF:n osalta eri lompakon toteutuksen arkkitehtuurimallien tekniset suunnitelmat ovat kesken.

ARF:issa puhuttiin siitä, että Person Identification Datan (PID) tarjoajan pitäisi olla mahdollisesti LoA tasoa high. Tuleeko tästä ongelmia Suomen tunnistusvälineiden suhteen?

Lompakko tulee olemaan tasoa high, joten tämän osalta ei tule ongelmia.

Miten DVV:n esimerkkisovellus asemoituu ARF-referenssi-implementaatioon nähden? 

DVV:n esimerkkisovellus  on kehitetty pääosin ennen komission referenssisovelluksen lähdekoodin julkaisua. Referenssisovelluksen protokollakirjastojen hyödyntämistä on selvitetty ja niiden hyödyntämistä arvioidaan tapauskohtaisesti osana tehtävää jatkokehitystä.

Mihin DC4EU:ssa tarvitaan  EBSI-lohkoketjua, eikö lompakko jo itsessään sisällä attribuuttien oikeellisuuden varmistamisen "mekanismit" vrt. muut käyttötapaukset?

Tämä on enemmän luottamusmalliin liittyvä kokeilu, ja ekosysteemissä on muitakin tapoja. DC4EU:ssa on kuitenkin nähty tärkeänä pilotoida lohkoketjua, koska opetussektori on sen käytössä pidemmällä. Lompakko tarvitsee tuekseen luottamusrekisterin, ja DC4EU:ssä rekisterin tarjoaa EBSI.

Onko EUDI Walletissa mDL (ajokortti) ISO 18013 -pohjainen vai EU:n oma OpenID-ratkaisu? 

EU-lompakon pitäisi tukea molempia, siis ISO 18013-5 ja OpenID (OpenID4VCI ja OpenID4VP).

Kysymyksiä muun kuin PID-attribuuttitodisteen (EAA) tuottamisesta ja lataamiseen esimerkkisovellukseen:

Tukeeko nykyiset lompakkosovellusversiot tätä ylipäätään, eli onko tätä tällä hetkellä mahdollista 3. osapuolena kehittää & testata?

Tukee ja on mahdollista, lisätietoa sivulta  https://wiki.dvv.fi/display/EDI/EUDIW+Demo+-+Credential+Issuance. Toiminnallisuutta ollaan koko ajan kehittämässä eteenpäin, mutta nykyisellään lompakko tukee ainoastaan mso_mdoc kredentiaaliformaattia ja Pre-Authorized Code Flow’ta.

Mitä vaatimuksia omien attribuuttitodisteiden myönnössä on? Onko vähintään oma testimyöntöpalvelu pystytettävä?

Käytännössä kyllä. Tähän löytyy esimerkkitoteutuksia GitHubista, esim. Italian tai Euroopan komission julkaisemana:

Onko sille oltava DVV:n (testi)palvelinvarmenne, allekirjoitusvarmenne, tms. vai voiko se olla kenen tahansa tahon myöntämä?

Lompakko ei tällä hetkellä tee luottamuspäätöksiä myöntävän tahon varmenteen pohjalta, vaan se on loppujen lopuksi luottavan osapuolen päätäntävallassa, luottaako se myöntävään osapuoleen. Lompakko on toistaiseksi tässä yhtälössä vain se tietoa välittävä osapuoli.

Onko attribuuttitodisteen myöntäjän/allekirjoittajan rekisteröidyttävä tavalla tai toisella jonkin uniikin tunnisteen saamiseksi (myös testi-/kehitysvaiheessa)?

Ei tarvitse, ainakaan vielä tässä vaiheessa. Luottamusmallin tarkentuessa tämäkin tulee tarkentumaan.

Voiko omassa kehityksessä nojautua DVV:n testiauktorisointipalveluun (onko sekään itseasiassa tuettu) vai pitääkö myös se ja mahdollisesti muitakin palveluja rakentaa itse?

Ei. Pre-Authorized Code Flow käytännössä olettaa, että käyttäjä on jo tunnistettu, joten sen auktorisoinnin voi myöntöpalveluun rakentaa millä tahansa mekanismilla. Testiversio voi alkuun toimia myös niin, että siinä ei ole minkäänlaista käyttäjän tunnistamista.

Ovatko kaikki testi-issuer palvelut julkisia (näkyvät osoitteessa < https://test.id.cloud.dvv.fi/eaa-provider-ui> ja/tai ”well known”-listoilla) vai voiko niitä kehittää ilman ne ovat julkisesti näkyvissä?

Ei tarvitse olla julkisia, mutta luonnollisesti käyttäjän tulee pystyä lompakkosovelluksellaan ottamaan yhteyttä palvelun rajapintoihin.

Mitä rajoitteita omiin attribuuttitodisteisiin liittyy tällä hetkellä? Attribuuttitodistuksien myöntö onnistuu vain Android-lompakkoon?

Tällä hetkellä kyllä. iOS-versioon tuki on tulossa myöhemmin.

Todistukset ovat myönnettävissä vain testi-PID-identiteetein/henkilötiedoin?

Todistuksissa ei käytännössä ole mitään teknistä sidettä siihen alla olevaan henkilön identiteettiin, mutta mikäli sellainen halutaan myöntöpalvelussa muodostaa, sovellus tarjoaa kasan testi-identiteettejä, joiden henkilötunnusta voidaan käyttää tämän linkityksen muodostamiseen.

Omia attribuuttitodistuksia ei voi käyttää/esittää (testipalveluissa)?

Sähköinen tunnistautuminen (OpenID4VP) ei vielä toistaiseksi tue ulkopuolisia todistuksia. Käyntiasioinnissa (ISO/IEC 18013-5) tuki on olemassa.

Omia attribuuttitodistuksia ei voi verifioida (lompakon toimesta)?

Lompakko pyrkii varmistamaan todistusten sisäisen integriteetin, mutta ei tällä hetkellä osaa arvioida onko tiedot luotettuja vai ei, koska mitään “luotettujen myöntäjien listaa” ei ole olemassa.

Omia attribuuttitodistuksia ei voi peruuttaa?

Ei voi vielä. ISO mdoc -muotoisten todisteiden revokointi tullee kehitykseen jahka sen toteutustapa varmistuu myöhemmissä standardiversioissa. SD-JWT -muotoisten todistusten revokointi on todennäköisesti mahdollista siinä vaiheessa, kun lompakko alkaa niitä tukea.

LSP-pilotit (Large Scale Pilots)

Mitä todisteita hyödyntäviä organisaatioita (Relying Party) osallistuu Suomesta LSP:ihin?

  • POTENTIAL-konsortion osalta asiointipalveluja selvitetään DVV:n ja Traficomin kanssa maaliskuun aikana. Traficom voisi periaatteessa toimia itse sekä QEAA providerina että Relying Partyna, jos käyttää lompakon kautta osoitettuja ajo-oikeustietoja omissa asiointipalveluissaan. Lisäksi DVV tulee POTENTIAL:ssa pilotointia viranomaisten sähköisissä asiontipalveluissa Suomi.fi-tunnistuksen kautta.
  • DC4EU-konsortion osalta asiointipalveluja kartoitetaan myös yhdessä OPH:n ja DVV:n kanssa. Yksi vaihtoehto on, että OPH voisi toimia itse Relying Partyna ja hyödyntää lompakoiden sisältämiä opiskelijatietoja omissa asiointipalveluissaan. Periaatteessa mukaan voisi tulla myös esim. korkeakouluja.
  • EWC-konsortiossa matkustamisen käyttötapauksen hyödyntäjänä on Suomesta Finnair. Oikeushenkilölompakon osalta selvitystä jatketaan yhdessä YD-hankkeen kanssa.

Mikä tulee olemaan Veron rooli EWC:n yrityslompakon toimittajana/selvittäjänä?

Enemmän selvittäjän rooli. On tarkoitus pilotoida oikeushenkilöille myönnettävää EUDI-lompakkoa, johon oikeushenkilö voi kerätä itseensä liittyviä todisteita ja osoittaa niitä käyntiasioinnissa. Kysymyksessä olisi pilvipohjainen lompakko. Tarkoitus on pilotoida oikeushenkilön PID:in liikkeelle lasku, oikeushenkilön lompakon liikkeelle lasku ja erikseen sovittavia, yritykseen liittyviä attribuuttitodistusten liikkeelle laskuja ja verifiointia. 

Onko eIDAS-regulaatioon tulossa myös ns. zero knowledge proof ja mitä tämä käytännössä tarkoittaisi? Onko tälle pilottikohteita?

Vuosien 2024-2025 pilotoinnissa ei toteuteta zero knowledge proof -ratkaisuja. Komissio on ottanut kantaa aiheeseen esitettyyn kysymykseen jo vuonna 2022, ja keskeisiltä osin näkemys ei vaikuta muuttuneen. Lompakot voivat tulevaisuudessa mahdollistaa tällaisia nollatietoratkaisuja, mutta niiden standardointityö on vielä keskeneräistä. 

Mobiiliajokortin pilotointiin liittyviä kysymyksiä:

Mitä Kostilla näkyy lompakossa, jos ajo-oikeus on peruutettu sen jälkeen, kun Kosti on hakenut ajokortin lompakkoon?
Ajo-oikeuden revokointimekanismia ei ole vielä täysin määritelty. Liiketoiminnan kannalta määrittely tulee tarkentumaan 4. ajokorttidirektiivin käsittelyn ja direktiivin perusteella annettavan komission täytäntöönpanoasetuksen myötä. Yleisenä vaatimuksena kuitenkin, että tarkastustilanteessa mobiiliajokortin tarkastaja saa tiedon onko ajo-oikeus voimassa vai ei. Vaatimuksen tekninen toteutustapa on vielä avoin.

Voisiko Kosti todistaa ajo-oikeutensa myös pelkällä kuvalla?
Jos tällä tarkoitetaan sitä, että Kosti näyttäisi "ajokortin kuvan" oman mobiililaitteensa näytöltä tarkastajalle, niin tämän ei pitäisi olla mahdollista. Pääperiaatteena on, että mobiiliajokortin tarkastaminen tehdään aina erillisellä lukijasovelluksella. Tietoja ei siis ole tarkoitus näyttää tai tarkistaa ns. paljaalla silmällä, vaan tiedot tarkistetaan aina lukijasovelluksen avulla ja esitetään tarkastajan laitteessa tai järjestelmässä.

Miten autovuokraamo tarkastaa ajoluvan voimassaolon?
ks. ensimmäinen kysymys. Autovuokraamo tarkistaa tiedot lukijasovelluksen avulla. Pyydetyt tiedot mobiiliajokortista tulevat tarkastajan nähtäviksi tarkastajan laitteessa tai järjestelmässä. Jos esitetty mobiiliajokortti ei ole voimassa, siitä tulee tieto tarkastajalle.

Jääkö ajokortin tarkistamisesta pelkkä logitieto vai vahvistettu todiste?
Tarkempi määrittely on vielä osin kesken. Ajatuksena on, että mobiiliajokortin tietojen alkuperäinen lähde (Traficom) ei saa tietää, missä ja milloin mobiiliajokortin tietoja on esitetty. Tietojen esittämisestä ja tarkastamisesta syntyy kyllä lokitietoa, mutta sen tarkempi tallennuskohde ja määrittely on vielä kesken. Eurooppalaisen digitaalisen identiteettilompakon toimintaperiaatteen mukaisesti lompakon käyttöä ei ole mahdollista seurata. Lisätietoja: Security and Privacy - EU Digital Identity Wallet - (europa.eu)

Onko mobiiliajokortilla oma korttinumeronsa vai onko se sama kuin fyysisessä ajokortissa?
Fyysisellä ja mobiiliajokortilla on erilliset korttinumerot.

Miten offline asiointi? Esim. vuokrauksessa ulkomainen henkilö, jolla ei ole toiminnassa vielä internetyhteys.
Offline-asioinnilla tarkoitetaan asiointia ilman internet-yhteyttä ja tällöin mobiiliajokortin tiedot haetaan suoraan mobiililaitteesta. Tarkastaja päättää oman riskiarvionsa pohjalta onko mobiililaitteesta saatu tieto riittävän ajantasainen.

Miten tarkkaan ajokortin osoittamisessa voi määritellä, mitä tietoja halutaan siirrettäväksi eli esim. ikä tietoa ei varmaan kaikessa tarvitse välittää, vaan riittää esim. ajokorttiluokka tai tieto löytyykö ajo-oikeus. 

Tarkastaja voi valita juuri ne tiedot, jotka ovat kyseisen asioinnin kannalta välttämättömiä. Lisätietoa EUn näkemyksistä jaettavan tiedon ja sen tarkkuustason suhteen voi lukea myös komission lompakkoa koskevalta sivulta https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/Security+and+Privacy . 

Ehkä sivuttiinkin jo, mutta kertaukseksi kertoisitteko a) mistä autovuokraamo saa lukijasovelluksen ja miten he integroivat sen omiin järjestelmiinsä, b) mistä vuokraaja saa lompakkosovelluksen jossa mobiiliajokortti VAI onko kyseessä puhdas Traficomin (vai kenen?) julkaisema "mobiiliajokorttilompakko"?

Tällä hetkellä pilotoinnissa käytössä OpenWallet Foundationin lukijasovellus. Vuokraajan lompakkosovellus on esiteltävä DVV:n esimerkkisovellus. eIDAS-asetuksen myötä jäsenvaltioille on odotettavissa velvollisuus toteuttaa kansalaisen käyttöön eurooppalaisella tasolla yhteentoimiva lompakkosovellus. Pilotoinnissa tällä hetkellä tehdyt toteutukset tuottavat osallistujille ymmärrystä lompakkosovelluksen toteuttamisesta, ja niissä on hyödynnetty eIDAS Toolbox arkkitehtuurista viitekehystä kehitystyössä. Lisätietoa uudistetusta eIDAS-asetuksesta voi lukea suomeksi  esimerkiksi VM:n sivuilta: https://vm.fi/eurooppalainen-lompakkosovellus


   

  • No labels