Министерски съвет
Портал за обществени консултации
Трансформацията на държавната администрация в дигитална изисква наличие на възможности за сигурно и надеждно установяване и проверка на самоличността на потребителите на електронни административни услуги. С оглед изграждането на технологична възможност за електронна идентификация чрез мобилно устройство, Министерството на електронното управление разработи техническа спецификация за изграждане на мобилно приложение за електронна идентификация и електронно подписване – BGID. Предвид огромната важност на процеса по електронна идентификация за цялостното развитие на електронното управление в Република България, техническата спецификация се публикува за обществена консултация с цел отчитане на приноса и мнението на всички заинтересовани страни преди обявяването на обществената поръчка.
Създадената технологична възможност за електронна идентификация чрез мобилно устройство ще разреши дългогодишния проблем с липсата на широко разпространено, достъпно, сигурно, надеждно, лесно за използване и безплатно средство за електронна идентификация, удобно разположено в мобилно устройство.
---
Пакет основни документи
Консултационен документ
---
Справка становища
---
С риск да се повторя добавям и следните предложения:
С риск да се повторя добавям и следните предложения:
Това е от голяма важност, за да се гарантира, че българските граждани могат да използват приложението за достъп до отговарящи на условията услуги на ЕС в други държави-членки. От решаващо значение е да се гарантира, че България може да работи на дигиталния пазар на ЕС, така че гарантирането на оперативна съвместимост и текущото съответствие с тези нововъзникващи стандарти от началото на този проект е от решаващо значение. Опитът за модернизиране на оперативната съвместимост след създаването на приложението няма да работи.
Това е от голяма важност, за да се гарантира, че българските граждани могат да използват приложението за достъп до отговарящи на условията услуги на ЕС в други държави-членки. От решаващо значение е да се гарантира, че България може да работи на дигиталния пазар на ЕС, така че гарантирането на оперативна съвместимост и текущото съответствие с тези нововъзникващи стандарти от началото на този проект е от решаващо значение. Опитът за модернизиране на оперативната съвместимост след създаването на приложението няма да работи.
Във връзка с обявено преразглеждането на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета чрез съобщението на Комисията от 19 февруари 2020 г., озаглавено „Изграждане на цифровото бъдеще на Европа“, с цел да се подобри неговата ефективност, да се даде възможност и на частния сектор да се възползва от него и да се насърчи използването на надеждна цифрова самоличност от всички европейци, както и с че в проекта за Изграждане на мобилно приложение за електронна идентификация и електронно подписване – BGID, е заложено съответствие с известните изисквания към европейски дигитален портфейл , с настоящето предлагаме промени, които в по-голяма степен да гарантират, че Българските граждани ще получат, решение отговарящо на най-съвременните изисквания за цифрова самоличност, като потребителят ще може да контролира количеството данни, предоставяни на доверяващите се страни, и ще бъде информиран за атрибутите, необходими за предоставянето на конкретна услуга.
1. В точка:
Да се добави
Термин | Описание | |
|---|---|---|
Европейски портфейл за цифрова самоличност | Лични цифрови портфейли, които позволяват на гражданите да се идентифицират по цифров път и да съхраняват и управляват данни за самоличност и официални документи в електронен формат. Тези документи може да включват свидетелство за управление на МПС, медицински рецепти или дипломи. С помощта на портфейла гражданите ще могат да доказват самоличността си, когато това е необходимо, за да получат достъп до услуги онлайн, да споделят цифрови документи или просто да докажат конкретна лична характеристика, например възраст, без да разкриват своята самоличност или други лични данни. Във всеки един момент гражданите ще имат пълен контрол върху данните, които споделят. |
|
2. В точка:
Настоящият проект обхваща дейности по изграждане на приложение за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
Да се промени, както следва:
Настоящият проект обхваща дейности по изграждане на приложение за портфейл за цифрова самоличност за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
3. В точка:
Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи:
…..
Да се добави в:
Международни стандарти:
4. В точка:
Очакваните резултати от изпълнението са:
Последния параграф да се промени, както следва:
Във връзка с обявено преразглеждането на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета чрез съобщението на Комисията от 19 февруари 2020 г., озаглавено „Изграждане на цифровото бъдеще на Европа“, с цел да се подобри неговата ефективност, да се даде възможност и на частния сектор да се възползва от него и да се насърчи използването на надеждна цифрова самоличност от всички европейци, както и с че в проекта за Изграждане на мобилно приложение за електронна идентификация и електронно подписване – BGID, е заложено съответствие с известните изисквания към европейски дигитален портфейл , с настоящето предлагаме промени, които в по-голяма степен да гарантират, че Българските граждани ще получат, решение отговарящо на най-съвременните изисквания за цифрова самоличност, като потребителят ще може да контролира количеството данни, предоставяни на доверяващите се страни, и ще бъде информиран за атрибутите, необходими за предоставянето на конкретна услуга.
1. В точка:
Да се добави
Термин | Описание | |
|---|---|---|
Европейски портфейл за цифрова самоличност | Лични цифрови портфейли, които позволяват на гражданите да се идентифицират по цифров път и да съхраняват и управляват данни за самоличност и официални документи в електронен формат. Тези документи може да включват свидетелство за управление на МПС, медицински рецепти или дипломи. С помощта на портфейла гражданите ще могат да доказват самоличността си, когато това е необходимо, за да получат достъп до услуги онлайн, да споделят цифрови документи или просто да докажат конкретна лична характеристика, например възраст, без да разкриват своята самоличност или други лични данни. Във всеки един момент гражданите ще имат пълен контрол върху данните, които споделят. |
|
2. В точка:
Настоящият проект обхваща дейности по изграждане на приложение за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
Да се промени, както следва:
Настоящият проект обхваща дейности по изграждане на приложение за портфейл за цифрова самоличност за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
3. В точка:
Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи:
…..
Да се добави в:
Международни стандарти:
4. В точка:
Очакваните резултати от изпълнението са:
Последния параграф да се промени, както следва:
Във връзка с обявено преразглеждането на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета чрез съобщението на Комисията от 19 февруари 2020 г., озаглавено „Изграждане на цифровото бъдеще на Европа“, с цел да се подобри неговата ефективност, да се даде възможност и на частния сектор да се възползва от него и да се насърчи използването на надеждна цифрова самоличност от всички европейци, както и с че в проекта за Изграждане на мобилно приложение за електронна идентификация и електронно подписване – BGID, е заложено съответствие с известните изисквания към европейски дигитален портфейл , с настоящето предлагаме промени, които в по-голяма степен да гарантират, че Българските граждани ще получат, решение отговарящо на най-съвременните изисквания за цифрова самоличност, като потребителят ще може да контролира количеството данни, предоставяни на доверяващите се страни, и ще бъде информиран за атрибутите, необходими за предоставянето на конкретна услуга.
1. В точка:
Да се добави
Термин | Описание | |
|---|---|---|
Европейски портфейл за цифрова самоличност | Лични цифрови портфейли, които позволяват на гражданите да се идентифицират по цифров път и да съхраняват и управляват данни за самоличност и официални документи в електронен формат. Тези документи може да включват свидетелство за управление на МПС, медицински рецепти или дипломи. С помощта на портфейла гражданите ще могат да доказват самоличността си, когато това е необходимо, за да получат достъп до услуги онлайн, да споделят цифрови документи или просто да докажат конкретна лична характеристика, например възраст, без да разкриват своята самоличност или други лични данни. Във всеки един момент гражданите ще имат пълен контрол върху данните, които споделят. |
|
2. В точка:
Настоящият проект обхваща дейности по изграждане на приложение за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
Да се промени, както следва:
Настоящият проект обхваща дейности по изграждане на приложение за портфейл за цифрова самоличност за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
3. В точка:
Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи:
…..
Да се добави в:
Международни стандарти:
4. В точка:
Очакваните резултати от изпълнението са:
Последния параграф да се промени, както следва:
Във връзка с обявено преразглеждането на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета чрез съобщението на Комисията от 19 февруари 2020 г., озаглавено „Изграждане на цифровото бъдеще на Европа“, с цел да се подобри неговата ефективност, да се даде възможност и на частния сектор да се възползва от него и да се насърчи използването на надеждна цифрова самоличност от всички европейци, както и с че в проекта за Изграждане на мобилно приложение за електронна идентификация и електронно подписване – BGID, е заложено съответствие с известните изисквания към европейски дигитален портфейл , с настоящето предлагаме промени, които в по-голяма степен да гарантират, че Българските граждани ще получат, решение отговарящо на най-съвременните изисквания за цифрова самоличност, като потребителят ще може да контролира количеството данни, предоставяни на доверяващите се страни, и ще бъде информиран за атрибутите, необходими за предоставянето на конкретна услуга.
1. В точка:
Да се добави
Термин | Описание | |
|---|---|---|
Европейски портфейл за цифрова самоличност | Лични цифрови портфейли, които позволяват на гражданите да се идентифицират по цифров път и да съхраняват и управляват данни за самоличност и официални документи в електронен формат. Тези документи може да включват свидетелство за управление на МПС, медицински рецепти или дипломи. С помощта на портфейла гражданите ще могат да доказват самоличността си, когато това е необходимо, за да получат достъп до услуги онлайн, да споделят цифрови документи или просто да докажат конкретна лична характеристика, например възраст, без да разкриват своята самоличност или други лични данни. Във всеки един момент гражданите ще имат пълен контрол върху данните, които споделят. |
|
2. В точка:
Настоящият проект обхваща дейности по изграждане на приложение за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
Да се промени, както следва:
Настоящият проект обхваща дейности по изграждане на приложение за портфейл за цифрова самоличност за мобилна електронна идентификация и подписване BGID, като целите на проекта са реализират въвеждане на използването на идентификация на потребителите посредством национален електронен идентификатор.
3. В точка:
Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи:
…..
Да се добави в:
Международни стандарти:
4. В точка:
Очакваните резултати от изпълнението са:
Последния параграф да се промени, както следва:
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Частни схеми за е-ИД поддържат двата ДКЕУУ - БОРИКА АД и Евротръст.
Днес е Националия ни празник ... На всички „ЧЕСТИТО“ ...
А сега кратък коментар по т.н. Техническа спецификация за BGID !
Забележете, Спецификацията е за мобилно приложение за е-идентификация и е-подпис, т.е. за нещо, което „виси ей-така свободно“, а не в обхвата на изпълнение на национална ТЕХНИЧЕСКА СХЕМА ЗА е-ИД и е-подпис (било то усъвъшенстван или квалифициран). Та нали имаме Закон за електронната иденти.фикация (ЗЕИ), който е приет и „втасва“ от няколко години... . Само е споменато, че това приложение следва да се осъществи в съответствие със съответстващите и известни нормативни актове за е-управление (включително и ЗЕИ). И понеже е за е-ИД, най-вече трябва да съответства на ЗЕИ. А това е възможно само ако приложението се „потопи“ (т.е.работи) в установена и изградена национална ТЕХНИЧЕСКА СХЕМА за е-идентификация с нейните субекти-участници в схемата (Орган на е-ИД – МВР, съответни Администратор(и) (напр. ДКЕУУ), Център/по-скоро Центрове за валидация и техните ИТ-системи и Регистри, и най накрая лицата, които ще ползват приложението). Така, че мобилното приложение е последната „брънка“ на СХЕМАТА !!!
В този смисъл, добре е в Техническата спецификация да има отделен раздел, определящ една ВАЛИДНА национална схема за еИД (ако има/е взето конкретно решение), така че бъдещата ОП за мобилното BGID да адресира тази схема. Още повече, че към настоящия момент вече има имплементирани и успешно се ползват технически решения базирани на мобилни приложения за издаване, регистрация, валидация и поддръжка на е-ИД и на мобилен/облачен КЕП на физически лица и такива, представляващи юридически лица. Това са частни схеми за еИД, които сравнително бързо и лесно могат да се изградат до национален обхват (в предвид много краткия период за реализация на BGID) и впоследствие да се нотифицират като национални-частни такива. Примери за такъв спешен подход в Европейския съюз има много ...
Ако има такъв раздел в предлаганата Техническа спецификация, бъдещета ОП ще адресира много точно поченциални и успешни участници в реализацията на BGID.
А и още нещо, което не следва да се забравя – промените в Регламент 910/2014 на ЕС за удостоверителните услуги (и специално за е-идентификацията). Като следствие – това е European digital identity Wallet (както мобилен, така и web-базиран), който ще адресира както националната така и през-граничната е-идентификация заедво с доставка на валидирани е-атестати/атрибути за лицата.
Б. Баев
Днес е Националия ни празник ... На всички „ЧЕСТИТО“ ...
А сега кратък коментар по т.н. Техническа спецификация за BGID !
Забележете, Спецификацията е за мобилно приложение за е-идентификация и е-подпис, т.е. за нещо, което „виси ей-така свободно“, а не в обхвата на изпълнение на национална ТЕХНИЧЕСКА СХЕМА ЗА е-ИД и е-подпис (било то усъвъшенстван или квалифициран). Та нали имаме Закон за електронната иденти.фикация (ЗЕИ), който е приет и „втасва“ от няколко години... . Само е споменато, че това приложение следва да се осъществи в съответствие със съответстващите и известни нормативни актове за е-управление (включително и ЗЕИ). И понеже е за е-ИД, най-вече трябва да съответства на ЗЕИ. А това е възможно само ако приложението се „потопи“ (т.е.работи) в установена и изградена национална ТЕХНИЧЕСКА СХЕМА за е-идентификация с нейните субекти-участници в схемата (Орган на е-ИД – МВР, съответни Администратор(и) (напр. ДКЕУУ), Център/по-скоро Центрове за валидация и техните ИТ-системи и Регистри, и най накрая лицата, които ще ползват приложението). Така, че мобилното приложение е последната „брънка“ на СХЕМАТА !!!
В този смисъл, добре е в Техническата спецификация да има отделен раздел, определящ една ВАЛИДНА национална схема за еИД (ако има/е взето конкретно решение), така че бъдещата ОП за мобилното BGID да адресира тази схема. Още повече, че към настоящия момент вече има имплементирани и успешно се ползват технически решения базирани на мобилни приложения за издаване, регистрация, валидация и поддръжка на е-ИД и на мобилен/облачен КЕП на физически лица и такива, представляващи юридически лица. Това са частни схеми за еИД, които сравнително бързо и лесно могат да се изградат до национален обхват (в предвид много краткия период за реализация на BGID) и впоследствие да се нотифицират като национални-частни такива. Примери за такъв спешен подход в Европейския съюз има много ...
Ако има такъв раздел в предлаганата Техническа спецификация, бъдещета ОП ще адресира много точно поченциални и успешни участници в реализацията на BGID.
А и още нещо, което не следва да се забравя – промените в Регламент 910/2014 на ЕС за удостоверителните услуги (и специално за е-идентификацията). Като следствие – това е European digital identity Wallet (както мобилен, така и web-базиран), който ще адресира както националната така и през-граничната е-идентификация заедво с доставка на валидирани е-атестати/атрибути за лицата.
Б. Баев
А как биха реагирали от ЕК/ЕС, ако бъдат реализирани и двете системи и се окажем с два различни root CA, които претендират да издават валидна електронна идентичност?!
И не на последно място, използването на УЕИ като подпис не е уредено нито в закона за електронна идентификация, нито в правилника за прилагането му. В тази връзка според мен е редно първо да се направят промените в закона, а не първо да се напише софтуера и след това фирмата, която го прави, да предложи и съответните законови промени, както е и написано в текущата спецификация. Това не би било проблем за електронната идентификация като част от проекта „поколение 2019“, тъй като е предвидено системите трябва да се адаптират при промени в законодателството.
Румен Николов
А как биха реагирали от ЕК/ЕС, ако бъдат реализирани и двете системи и се окажем с два различни root CA, които претендират да издават валидна електронна идентичност?!
И не на последно място, използването на УЕИ като подпис не е уредено нито в закона за електронна идентификация, нито в правилника за прилагането му. В тази връзка според мен е редно първо да се направят промените в закона, а не първо да се напише софтуера и след това фирмата, която го прави, да предложи и съответните законови промени, както е и написано в текущата спецификация. Това не би било проблем за електронната идентификация като част от проекта „поколение 2019“, тъй като е предвидено системите трябва да се адаптират при промени в законодателството.
Румен Николов
Идеята за електронна идентификация чрез телефон не е лоша като цяло. Описаната в този проект, според мен обаче, има доста проблеми и дава повече въпроси, отколкото отговори.
КЕП е с валидност до 3 години и не би следвало да се използва до края на изтичането на валидността му, а не както е описано в т. 4 от текущата спецификация – „до 1 година след влизане в продукционен режим на националната схема по ЗЕИ“.
Доколкото става ясно т. 4 от текущата документация, КЕП, ПИК на НАП/НОИ, и УКД на НЗОК могат и в момента се използват за достъп до електронни административни услуги само в България. Целта на този проект е САМО да осигури възможност за ползване на трансгранични електронни услуги в рамките на ЕС: „Чрез посочените средства обаче българските граждани не могат да се идентифицират, когато заявяват електронни административни услуги в други държави-членки на Европейския съюз, което препятства възможността за ползване на трансгранични електронни услуги в рамките на ЕС.“
Кое налага необходимостта да осигурим ползване на трансгранични електронни услуги в рамките на ЕС в момента? В техническата спецификация по този проект се споменават САМО електронни административни услуги в България! А за тези услуги и в момента има работеща електронна идентификация!
В тази връзка – ако ще бъде правена реализация на проекта в този му вид, е необходимо да бъде добавен и регистър/списък на наличните трансгранични електронни услуги в рамките на ЕС, от които ще могат да се възползват българските граждани.
Не мисля, че желаещите да използват трансгранични електронни услуги в рамките на ЕС, каквато е и целта на този проект, са толкова много, че да се реализира допълнителен проект за електронна идентификация.
Използването на смартфон/таблет или друго устройство е възможно съгласно техническата спецификация в Приложение 8 от обществената поръчка с наименование „Проектиране, изграждане и управление на Система за издаване на български лични документи поколение 2019“. УЕИ може да бъде записан на устройствата след като се регистрират от съответен Администратор в Подсистемата за управление на носители (ПУН). Но генерирането на електронния идентификатор, както и всички други регистри и процеси свързани с издаване на УЕИ, ще са изградени и няма нужда да бъдат дублирани. Т.е. така предложената схема за електронна идентификация ще дублира над 90% функционалностите и изискванията, описани в Техническата спецификация Приложение 8: „Изграждане на централизирана система за електронна идентификация“, която е част от обществената поръчка за документи „поколение 2019“, а за тази поръчка има и определен изпълнител.
Текущата система за персонализация на български лични документи стартира в началото на 2010 г. Техниката е на над 12 години, като на станциите за снемане на биометрични данни все още се използва Windows XP, която отдавна не се поддържа от Майкрософт. Стартирането на производство на документи „поколение 2019“ е предвидено за около 2 години след подписване на договора. Това значи, че трябва да бъде осигурена поддръжка на техниката към текущата система, която започва 13та година от амортизационния период за още минимум 2 години. Спирането или промяната на поръчката за документи „поколение 2019“ ще отнеме поне 2 години, които ще трябва да бъдат добавени към поддръжка на текущата система за издаване на лични документи. Колко човека имат работещ принтер на над 15 години?
Заслужава ли си да се стартира нова обществена поръчка за дейност, която всъщност до голямата си степен е част от вече стартирана обществена поръчка, на която има и определен изпълнител?
В момента идентификацията на граждани за достъп до електронните услуги на администрацията работи. Аз лично имам и ПИК на НАП, на НОИ и КЕП и използвам активно съществуващите електронни услуги. Не мисля обаче, че е необходимо дублирането на реализирането на националната схема за електронна идентификация и това дублиране да се оправдава само с цел ползване на трансгранични електронни услуги в рамките на ЕС. Условията за сигурна и надеждна електронна идентификация на гражданите при предоставяне на електронни административни услуги са заложени като част от обществената поръчка за лични документи „поколение 2019“.
Не е редно за едно и също нещо да се разходва два пъти обществен ресурс. Освен системите за издаване и регистрация на УЕИ ще бъде дублирана и PKI инфраструктурата (HSM устройства, сървъри …), които са и в другия проект.
Идеята за електронна идентификация чрез телефон не е лоша като цяло. Описаната в този проект, според мен обаче, има доста проблеми и дава повече въпроси, отколкото отговори.
КЕП е с валидност до 3 години и не би следвало да се използва до края на изтичането на валидността му, а не както е описано в т. 4 от текущата спецификация – „до 1 година след влизане в продукционен режим на националната схема по ЗЕИ“.
Доколкото става ясно т. 4 от текущата документация, КЕП, ПИК на НАП/НОИ, и УКД на НЗОК могат и в момента се използват за достъп до електронни административни услуги само в България. Целта на този проект е САМО да осигури възможност за ползване на трансгранични електронни услуги в рамките на ЕС: „Чрез посочените средства обаче българските граждани не могат да се идентифицират, когато заявяват електронни административни услуги в други държави-членки на Европейския съюз, което препятства възможността за ползване на трансгранични електронни услуги в рамките на ЕС.“
Кое налага необходимостта да осигурим ползване на трансгранични електронни услуги в рамките на ЕС в момента? В техническата спецификация по този проект се споменават САМО електронни административни услуги в България! А за тези услуги и в момента има работеща електронна идентификация!
В тази връзка – ако ще бъде правена реализация на проекта в този му вид, е необходимо да бъде добавен и регистър/списък на наличните трансгранични електронни услуги в рамките на ЕС, от които ще могат да се възползват българските граждани.
Не мисля, че желаещите да използват трансгранични електронни услуги в рамките на ЕС, каквато е и целта на този проект, са толкова много, че да се реализира допълнителен проект за електронна идентификация.
Използването на смартфон/таблет или друго устройство е възможно съгласно техническата спецификация в Приложение 8 от обществената поръчка с наименование „Проектиране, изграждане и управление на Система за издаване на български лични документи поколение 2019“. УЕИ може да бъде записан на устройствата след като се регистрират от съответен Администратор в Подсистемата за управление на носители (ПУН). Но генерирането на електронния идентификатор, както и всички други регистри и процеси свързани с издаване на УЕИ, ще са изградени и няма нужда да бъдат дублирани. Т.е. така предложената схема за електронна идентификация ще дублира над 90% функционалностите и изискванията, описани в Техническата спецификация Приложение 8: „Изграждане на централизирана система за електронна идентификация“, която е част от обществената поръчка за документи „поколение 2019“, а за тази поръчка има и определен изпълнител.
Текущата система за персонализация на български лични документи стартира в началото на 2010 г. Техниката е на над 12 години, като на станциите за снемане на биометрични данни все още се използва Windows XP, която отдавна не се поддържа от Майкрософт. Стартирането на производство на документи „поколение 2019“ е предвидено за около 2 години след подписване на договора. Това значи, че трябва да бъде осигурена поддръжка на техниката към текущата система, която започва 13та година от амортизационния период за още минимум 2 години. Спирането или промяната на поръчката за документи „поколение 2019“ ще отнеме поне 2 години, които ще трябва да бъдат добавени към поддръжка на текущата система за издаване на лични документи. Колко човека имат работещ принтер на над 15 години?
Заслужава ли си да се стартира нова обществена поръчка за дейност, която всъщност до голямата си степен е част от вече стартирана обществена поръчка, на която има и определен изпълнител?
В момента идентификацията на граждани за достъп до електронните услуги на администрацията работи. Аз лично имам и ПИК на НАП, на НОИ и КЕП и използвам активно съществуващите електронни услуги. Не мисля обаче, че е необходимо дублирането на реализирането на националната схема за електронна идентификация и това дублиране да се оправдава само с цел ползване на трансгранични електронни услуги в рамките на ЕС. Условията за сигурна и надеждна електронна идентификация на гражданите при предоставяне на електронни административни услуги са заложени като част от обществената поръчка за лични документи „поколение 2019“.
Не е редно за едно и също нещо да се разходва два пъти обществен ресурс. Освен системите за издаване и регистрация на УЕИ ще бъде дублирана и PKI инфраструктурата (HSM устройства, сървъри …), които са и в другия проект.
Поздравявам колегите за публичното представяне на спецификацията.
Ето няколко мисли по представения текст:
1. Документът би спечели, ако се знае, кой е авторът или авторите. От една страна ще сме сигурни, че авторът няма да е свързан с бъдещия изпълнител. От друга страна всичко, което ще бъде написано в крайния вариант, ще има по-голяма тежест и отговорност.
2. Спецификацията планира с обществена поръчка да се избере изпълнител, на който да се възложи отговорната задача за изгради национален модел за създаване, разпределение и използване на криптографски ключове за целите на реализирането на електронната идентификация и подписване. Това трябва да се извърши в Дейност 1.
Ако Възложителят одобри резултата на Дейност 1, наречен “Системен проект”, Изпълнителят ще продължи с разработването на необходимия софтуер.
Проблемите, които виждаме в това направение, са следните:
Поздравявам колегите за публичното представяне на спецификацията.
Ето няколко мисли по представения текст:
1. Документът би спечели, ако се знае, кой е авторът или авторите. От една страна ще сме сигурни, че авторът няма да е свързан с бъдещия изпълнител. От друга страна всичко, което ще бъде написано в крайния вариант, ще има по-голяма тежест и отговорност.
2. Спецификацията планира с обществена поръчка да се избере изпълнител, на който да се възложи отговорната задача за изгради национален модел за създаване, разпределение и използване на криптографски ключове за целите на реализирането на електронната идентификация и подписване. Това трябва да се извърши в Дейност 1.
Ако Възложителят одобри резултата на Дейност 1, наречен “Системен проект”, Изпълнителят ще продължи с разработването на необходимия софтуер.
Проблемите, които виждаме в това направение, са следните:
Въпросната система ще представлява единна точка на достъп до държавната администрация.
Това я превръща в "single point of failure".
От тази гледна точка е необходимо при избора на проект да се направи анализ на неговата сигурност.
Това, според мен се вижда в почти всички коментари.
Затова смятам за уместно, да се привлече трета страна от сферата на киберсигурността, като допълнителен одит при избора на изпълнител и оценка на неговата работа.
Въпросната система ще представлява единна точка на достъп до държавната администрация.
Това я превръща в "single point of failure".
От тази гледна точка е необходимо при избора на проект да се направи анализ на неговата сигурност.
Това, според мен се вижда в почти всички коментари.
Затова смятам за уместно, да се привлече трета страна от сферата на киберсигурността, като допълнителен одит при избора на изпълнител и оценка на неговата работа.
Предаването само на хеш и описание при подписване, може да доведе до това потребителя, без да подозоира, да подпише различен документ. Няма възможност такова подписване да може да бъде оспорено, тъй като потребителя никога не е имал достъп до документа - обект на подписване, за да може да провери неговата хеш стойност.
Странта, която изчизлява хеша трябва да има доверието на потребителя. Тъй като това условие е трудно да бъде постигнато, трябва да има възможност документа да бъде прегледан и неговия хеш да бъде изчислен на самото мобилно устройство. След сравнение на предоставения и изчисления хеш да се продължи с процеса на подписване.
Може да се специфицира списък от поддържани формати за документи за подписване, които да могат да бъдат преглеждани на мобилни устройства.
Алтернативно, описанието от т. 8.2.8 трябва да бъде част от процедурата по подписване, с локално изчисляване на хеш и включването на този хеш в електронния подпис.
Тази мярка би увеличила увереността у потребителя, че подписва това, което вижда.
Предаването само на хеш и описание при подписване, може да доведе до това потребителя, без да подозоира, да подпише различен документ. Няма възможност такова подписване да може да бъде оспорено, тъй като потребителя никога не е имал достъп до документа - обект на подписване, за да може да провери неговата хеш стойност.
Странта, която изчизлява хеша трябва да има доверието на потребителя. Тъй като това условие е трудно да бъде постигнато, трябва да има възможност документа да бъде прегледан и неговия хеш да бъде изчислен на самото мобилно устройство. След сравнение на предоставения и изчисления хеш да се продължи с процеса на подписване.
Може да се специфицира списък от поддържани формати за документи за подписване, които да могат да бъдат преглеждани на мобилни устройства.
Алтернативно, описанието от т. 8.2.8 трябва да бъде част от процедурата по подписване, с локално изчисляване на хеш и включването на този хеш в електронния подпис.
Тази мярка би увеличила увереността у потребителя, че подписва това, което вижда.
Предлагам да се проведе прозрачна процедура по ЗОП и да има реално състезание за избор на изпълнител. Злите езици говорят, че изпълнителя е вече известен и работи по реализацията и това е Информационно обслужване АД. Ако е така защо ни губите времето и говорите за прозрачност и равен старт на бизнеса в България. То и преди ИО АД вземаше, но нали щеше да има промяна. То в случай не промя, то и замяна или подмяна НЯМА.
Предлагам да се гарантира, че Информационно обслужване АД няма да е предизвестения изпълнител на тази поръчка.
Предлагам да се проведе прозрачна процедура по ЗОП и да има реално състезание за избор на изпълнител. Злите езици говорят, че изпълнителя е вече известен и работи по реализацията и това е Информационно обслужване АД. Ако е така защо ни губите времето и говорите за прозрачност и равен старт на бизнеса в България. То и преди ИО АД вземаше, но нали щеше да има промяна. То в случай не промя, то и замяна или подмяна НЯМА.
Предлагам да се гарантира, че Информационно обслужване АД няма да е предизвестения изпълнител на тази поръчка.
1. Agile нали това е техническа грешка. Моля се да е така. Нека не смесваме правенето на сайт със сериозен проект, който ще гарантира идентификацията на лицата пред държавата. Още повече, че този подход противоречи на етапите в т.6 и дейностите в т. 8. Кое ще правите с Agile - модела по т. 8.1 или разработката по следващата дейност. предлагам да се преразгледа изискваната методология за разработка и да се заложи класическа.
2. Документация - нищо по темата или то щото ИО АД ще го прави, няма нужда от документация. И недейте се кри зад т.9.2 Системен проект. Толкова жалко са описани изискванията към него, че повече не може и да бъде. МТИТС и ДАЕУ залагаха на точен опис на изискваните документи като част от разработката и не знам кой го разпозна като лоша практика. Предлагам да се опишат в детайли цялата очаквана документация по проекта, включително конвенция за писане на код, за да няма после - Ние го публикувахме, ама само ИО АД може да си го чете.
3. Българите в чужбина пак сте ни забравили - или пак извади си ПИК, КИН, КЕП (ама български, защото сме родолюбци). Стига! Само не отхвърляйте бележката с .... то паспорта е за тях. А за чужденците - на първо място гражданите на държавите-членки на ЕС - няма ги и това е дискреминация или BGiD e само за българи и електронните услуги са само за тях. Придлагам да се включат ясни изисквания в спецификацията за възможност за идентификация за всички групи граждани. Да не забравяме и лицата с двойно гражданство.
4. По изискванията за гаранционна поддръжка и наличност на системата - Нали не си мечтаете да минете с тези изисквания - размити и на практика винаги оправдаващи изпълнителя ИО АД. Предлагам да се въведат изисквания за 365/24/7 подръжка, ясен SLA - например присумарно един час неработоспособност на годишна база - глоба от 20 % от стойността на проекта, време за реакция половин час, време за отстраняване на инцидент или решение възстановяващо работоспособността 1 час, изисквания за архитектура, която да гарантира пълна функционална резервираност на решението.
Много слаба първа спецификация, г-н Божанов - личи си че сте я бързали и правили на коляно. Дано актуализирания вариант също мине обществено обсъждане. Проектът е много важен и си заслужава внимание.
1. Agile нали това е техническа грешка. Моля се да е така. Нека не смесваме правенето на сайт със сериозен проект, който ще гарантира идентификацията на лицата пред държавата. Още повече, че този подход противоречи на етапите в т.6 и дейностите в т. 8. Кое ще правите с Agile - модела по т. 8.1 или разработката по следващата дейност. предлагам да се преразгледа изискваната методология за разработка и да се заложи класическа.
2. Документация - нищо по темата или то щото ИО АД ще го прави, няма нужда от документация. И недейте се кри зад т.9.2 Системен проект. Толкова жалко са описани изискванията към него, че повече не може и да бъде. МТИТС и ДАЕУ залагаха на точен опис на изискваните документи като част от разработката и не знам кой го разпозна като лоша практика. Предлагам да се опишат в детайли цялата очаквана документация по проекта, включително конвенция за писане на код, за да няма после - Ние го публикувахме, ама само ИО АД може да си го чете.
3. Българите в чужбина пак сте ни забравили - или пак извади си ПИК, КИН, КЕП (ама български, защото сме родолюбци). Стига! Само не отхвърляйте бележката с .... то паспорта е за тях. А за чужденците - на първо място гражданите на държавите-членки на ЕС - няма ги и това е дискреминация или BGiD e само за българи и електронните услуги са само за тях. Придлагам да се включат ясни изисквания в спецификацията за възможност за идентификация за всички групи граждани. Да не забравяме и лицата с двойно гражданство.
4. По изискванията за гаранционна поддръжка и наличност на системата - Нали не си мечтаете да минете с тези изисквания - размити и на практика винаги оправдаващи изпълнителя ИО АД. Предлагам да се въведат изисквания за 365/24/7 подръжка, ясен SLA - например присумарно един час неработоспособност на годишна база - глоба от 20 % от стойността на проекта, време за реакция половин час, време за отстраняване на инцидент или решение възстановяващо работоспособността 1 час, изисквания за архитектура, която да гарантира пълна функционална резервираност на решението.
Много слаба първа спецификация, г-н Божанов - личи си че сте я бързали и правили на коляно. Дано актуализирания вариант също мине обществено обсъждане. Проектът е много важен и си заслужава внимание.
Привет,
Предложението ми е да отпаднат изцяло изискванията за събиране/съхраняване/използване на телефонен номер: "При регистрация, гражданите трябва да посочат и мобилен телефон и имейл адрес."
и тук:
"В сървърната част на системата трябва да се съхранява:
...
контактна информация (имейл и телефон)"
и тук:
"Управление на устройствата
...
Привет,
Предложението ми е да отпаднат изцяло изискванията за събиране/съхраняване/използване на телефонен номер: "При регистрация, гражданите трябва да посочат и мобилен телефон и имейл адрес."
и тук:
"В сървърната част на системата трябва да се съхранява:
...
контактна информация (имейл и телефон)"
и тук:
"Управление на устройствата
...
Това е добър feature, но пък от гледна точка на "surveilance" е малко ограничаващо. и не, аргумента "ама вие какво ще кирете?" не е валиден.
Нека има информация за потербителя, и възможност той да поиска блокиране на ID-то си, но не и системата да го блокира автоматично.
Това е добър feature, но пък от гледна точка на "surveilance" е малко ограничаващо. и не, аргумента "ама вие какво ще кирете?" не е валиден.
Нека има информация за потербителя, и възможност той да поиска блокиране на ID-то си, но не и системата да го блокира автоматично.
осъзнавам че това не е целта за момента, но би било много удобно да се добави функционалност за идентификация и пред физически лица в самото приложение. Т.е. да мога да покажа на екрана информацията нужна за удостоверение + QR код за проверка на тази информация.
осъзнавам нуждата от промяна на законовата рамка, но мисля че тук му е мястото на един такъв feature.
осъзнавам че това не е целта за момента, но би било много удобно да се добави функционалност за идентификация и пред физически лица в самото приложение. Т.е. да мога да покажа на екрана информацията нужна за удостоверение + QR код за проверка на тази информация.
осъзнавам нуждата от промяна на законовата рамка, но мисля че тук му е мястото на един такъв feature.
Спецификацията е твърде техническа, не е продуктова.
-Приложението трябва да бъде тествано на ниво концепция с реални хора. Дали пенсионери или ниско образовани граждани биха могли да се регистрират и ползват приложението сами или ще бъдат дискриминирани?
-Изплозването на геолокация и камера изисква изричното разрешение от потребителя, което отново може да доведе до фал старт.
-Чужденците у нас могат ли да се възползват от това приложение ако нямат български документи на самоличност?
- Apple често де-регистрират приложения които използват геолокация или лични данни. Има ли план при такава ситуация? Покрива ли се от гаранционните условия?
Спецификацията е твърде техническа, не е продуктова.
-Приложението трябва да бъде тествано на ниво концепция с реални хора. Дали пенсионери или ниско образовани граждани биха могли да се регистрират и ползват приложението сами или ще бъдат дискриминирани?
-Изплозването на геолокация и камера изисква изричното разрешение от потребителя, което отново може да доведе до фал старт.
-Чужденците у нас могат ли да се възползват от това приложение ако нямат български документи на самоличност?
- Apple често де-регистрират приложения които използват геолокация или лични данни. Има ли план при такава ситуация? Покрива ли се от гаранционните условия?
Предложението е дискриминационно и дефакто изисква гражданите да използват не просто точно определени операционни системи, но и то с минимално изисквана версия.
Няма никаква причина държавата да спомага допълнително за монопола на Apple/Google в тази посока. Или го правите като хората - достъпно за всеки един гражданин, или изобщо не го правите.
Предложението е дискриминационно и дефакто изисква гражданите да използват не просто точно определени операционни системи, но и то с минимално изисквана версия.
Няма никаква причина държавата да спомага допълнително за монопола на Apple/Google в тази посока. Или го правите като хората - достъпно за всеки един гражданин, или изобщо не го правите.
Здравейте, поздравления за ясно и точно написаното задание! Както знаем, лихвари и тартори на определени групи имат незаконната практика да събират лични карти и банкови карти на групи хора и ги ползват от тяхно име. Това задължително трябва да избегнем при електронната идентификация. Не трябва да се разрешава повече от едно активно устройство. Идентификация само с биометрични данни - лицево разпознаване или пръстов отпечатък без възможност за замяната им с PIN на телефона. На устройствата на Apple това е възможно с конфигурация. Това гарантира физическото присъствие на човека поне доколкото масовите технологии го позволят. Проблем е, че пръстовите отпечатъци могат да се конфигурират в настойките на телефона и е възможно да се въведат и на друг човек, т.е. може да се злоупотреби. Лицевото разпознаване също може да се конфигурира за друг човек и това са проблеми, за които предполагам бихме могли да потърсим решение. Но поне могат да се случат само със съдействието на собственика. Приложението трябва са работи само когато GPS приемникът има fix с добра точност, за да може да се проследи локацията при злоупотреби.
Здравейте, поздравления за ясно и точно написаното задание! Както знаем, лихвари и тартори на определени групи имат незаконната практика да събират лични карти и банкови карти на групи хора и ги ползват от тяхно име. Това задължително трябва да избегнем при електронната идентификация. Не трябва да се разрешава повече от едно активно устройство. Идентификация само с биометрични данни - лицево разпознаване или пръстов отпечатък без възможност за замяната им с PIN на телефона. На устройствата на Apple това е възможно с конфигурация. Това гарантира физическото присъствие на човека поне доколкото масовите технологии го позволят. Проблем е, че пръстовите отпечатъци могат да се конфигурират в настойките на телефона и е възможно да се въведат и на друг човек, т.е. може да се злоупотреби. Лицевото разпознаване също може да се конфигурира за друг човек и това са проблеми, за които предполагам бихме могли да потърсим решение. Но поне могат да се случат само със съдействието на собственика. Приложението трябва са работи само когато GPS приемникът има fix с добра точност, за да може да се проследи локацията при злоупотреби.
Здравейте,
Призовавам за поддръжка на комплексни пароли до 99 символа и поддръжка на MFA приложения и ключове като : Yubikey / Yubico
Имаики предвид че потребителите ще имат разнородни устройства и версии на OS в разработката и тестването на мобилните приложение трябва да се заложи поддръжка на повече версии и OEM специфично за Android. Android 7 - 12 включително, Поради разликата между stock Android & OEM версиите и т.н.
Също така призовавам за разработване на Native приложения тъй като сигурността може да се обезпечи по-лесно спрямо Cordova, Xamarin и други multi-platform технологии и плюс това в бъдеще ще бъде по-лесно надграждането на приложенията, обновления и адаптация към нови версии на OS.
https://developer.android.com/topic/security/best-practices#java
Здравейте,
Призовавам за поддръжка на комплексни пароли до 99 символа и поддръжка на MFA приложения и ключове като : Yubikey / Yubico
Имаики предвид че потребителите ще имат разнородни устройства и версии на OS в разработката и тестването на мобилните приложение трябва да се заложи поддръжка на повече версии и OEM специфично за Android. Android 7 - 12 включително, Поради разликата между stock Android & OEM версиите и т.н.
Също така призовавам за разработване на Native приложения тъй като сигурността може да се обезпечи по-лесно спрямо Cordova, Xamarin и други multi-platform технологии и плюс това в бъдеще ще бъде по-лесно надграждането на приложенията, обновления и адаптация към нови версии на OS.
https://developer.android.com/topic/security/best-practices#java
Здравейте,
Освен направените вече коментари, според мен трябва да бъдат уточнени и ясно записани няколко малки детайла:
1. т.8.3.1 и т.8.4.1 - Мобилно приложение разработено за операционните системи Android и iOS, работещо на смартфони, с минимална версия на оперционната система, както следва:
Според закона "Мобилно приложение" е приложение работещо на мобилни у-ва - "като смартфон или таблет". Следователно се получава двузначност, тъй като Android OS се поддържа, както на таблет, така и на смартфон, докато от Apple решиха наскоро да сменят името на операционната с-ма на техните таблети на iPadOS. Ясно е, че iPadOS, стъпва изцяло на iOS, но това уточнение ще внесе яснота дали приложението ще бъде разработено само за смартфони или както за смартфони, така и за таблети. В случай, че е за двата типа устройства , то тогава със сигурност scope-ът ще се увеличи, макар и с малко.
2. т. 6.4 - частта "..., за да се демонстрира", според мен, трябва да бъде заменена с "..., за да бъде валидирано". "Валидацията" означава много повече в софтуерната разработка, а именно, че ще бъде изпълнено тестване, чрез различни техники, което всъщност ще демонстрира правилното изпълнение на изискванията.
ISTQB definition - "validation:
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled."
Здравейте,
Освен направените вече коментари, според мен трябва да бъдат уточнени и ясно записани няколко малки детайла:
1. т.8.3.1 и т.8.4.1 - Мобилно приложение разработено за операционните системи Android и iOS, работещо на смартфони, с минимална версия на оперционната система, както следва:
Според закона "Мобилно приложение" е приложение работещо на мобилни у-ва - "като смартфон или таблет". Следователно се получава двузначност, тъй като Android OS се поддържа, както на таблет, така и на смартфон, докато от Apple решиха наскоро да сменят името на операционната с-ма на техните таблети на iPadOS. Ясно е, че iPadOS, стъпва изцяло на iOS, но това уточнение ще внесе яснота дали приложението ще бъде разработено само за смартфони или както за смартфони, така и за таблети. В случай, че е за двата типа устройства , то тогава със сигурност scope-ът ще се увеличи, макар и с малко.
2. т. 6.4 - частта "..., за да се демонстрира", според мен, трябва да бъде заменена с "..., за да бъде валидирано". "Валидацията" означава много повече в софтуерната разработка, а именно, че ще бъде изпълнено тестване, чрез различни техники, което всъщност ще демонстрира правилното изпълнение на изискванията.
ISTQB definition - "validation:
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled."
По отношение на 7.2.3:
Бих добавил и "Pilot" логическа среда. Нейното място е между Staging (Test) и Production. Pilot е среда, максимално близка до реалната, където се извършва тестване на Release Candidate версия на софтуера с натоварване максимално близко до реалността.
По отношение на 7.2.5:
Системата за ежедневен бекъп на данните следва да бъде организирана по два параметър: географски и локален. Географски е за сигурност на съхранението на данните и застраховка (защита) от непредвидени ситуации - пожар, земетресение,... Локален е за скорост на възстановяване.
По отношение на 7.2.3:
Бих добавил и "Pilot" логическа среда. Нейното място е между Staging (Test) и Production. Pilot е среда, максимално близка до реалната, където се извършва тестване на Release Candidate версия на софтуера с натоварване максимално близко до реалността.
По отношение на 7.2.5:
Системата за ежедневен бекъп на данните следва да бъде организирана по два параметър: географски и локален. Географски е за сигурност на съхранението на данните и застраховка (защита) от непредвидени ситуации - пожар, земетресение,... Локален е за скорост на възстановяване.
HSM са споментаи май само на едно място. Мисля че трябва да бъде казано изрично като изискване за съхраняване на ключовете на сървера.
има на много места в текста "или" (напр. или PIN или биометрика). знам че се опитвате да направите заданието възможно най-отворено за различни технологии, но на мен ми изглежда че печелившия участник ще избере пътя на на най-малкото съпротивление и ще направи само по-лесния вариант, което ще е пак стъпка в правилната посока, но ми се иска да се поддържат повече възможности от начало.
говорейки за възможности, мисля че е добра идея в такъв проект да бъде заложена и извън-гаранционна поддръжка по зададени параметри за да може системата да бъде доразвивана бързо при възникване на нови изисквания на базата да този спечелен договор. Нека тази поддръжка да бъде период от поне 5 години и да има някакви рамки, но да я има и да не се чуди министерството как да си поиска някоя бърза доработка само защото трябва да пуска нова обществена поръчка.
Иначе посоката на документа е правилната и дори и в този вид да остане е огромна крачка напред!
HSM са споментаи май само на едно място. Мисля че трябва да бъде казано изрично като изискване за съхраняване на ключовете на сървера.
има на много места в текста "или" (напр. или PIN или биометрика). знам че се опитвате да направите заданието възможно най-отворено за различни технологии, но на мен ми изглежда че печелившия участник ще избере пътя на на най-малкото съпротивление и ще направи само по-лесния вариант, което ще е пак стъпка в правилната посока, но ми се иска да се поддържат повече възможности от начало.
говорейки за възможности, мисля че е добра идея в такъв проект да бъде заложена и извън-гаранционна поддръжка по зададени параметри за да може системата да бъде доразвивана бързо при възникване на нови изисквания на базата да този спечелен договор. Нека тази поддръжка да бъде период от поне 5 години и да има някакви рамки, но да я има и да не се чуди министерството как да си поиска някоя бърза доработка само защото трябва да пуска нова обществена поръчка.
Иначе посоката на документа е правилната и дори и в този вид да остане е огромна крачка напред!
Здравейте,
Поздравления за проекта, само лек коментар относно текст в т. 8.2.2 "При регистрация, гражданите трябва да посочат и мобилен телефон и имейл адрес."
Не смятам за удачно системата да изисква телефонен номер за завършване на регистрация. Често има граждани които имат устройства, но не и активен номер, било то по тяхно желание или не. Ако все пак се иска телефонен номер нека то е по желание за получаване на определени уведомления. Тъй като приложението може да доставя нотификации/известия и без него. И да може да се избира предпочитан метод за връзка. Ако има няколко, email, телефонен номер, нотфикации.
Другото на което смятам, че може да се обърне внимание е прехвърлянето на друго у-во. Добре е да се заложи метод с паспорт и с новите лични карти, с чип тъй като те ще съществуват, а ПИК на НОИ/НАП най-вероятно ще бъде закрит като система. За да може да има алтернатива на СМС и да не зависи достъпа към е-услуги от достъп до телефонен номер.
Благодаря Ви!
Здравейте,
Поздравления за проекта, само лек коментар относно текст в т. 8.2.2 "При регистрация, гражданите трябва да посочат и мобилен телефон и имейл адрес."
Не смятам за удачно системата да изисква телефонен номер за завършване на регистрация. Често има граждани които имат устройства, но не и активен номер, било то по тяхно желание или не. Ако все пак се иска телефонен номер нека то е по желание за получаване на определени уведомления. Тъй като приложението може да доставя нотификации/известия и без него. И да може да се избира предпочитан метод за връзка. Ако има няколко, email, телефонен номер, нотфикации.
Другото на което смятам, че може да се обърне внимание е прехвърлянето на друго у-во. Добре е да се заложи метод с паспорт и с новите лични карти, с чип тъй като те ще съществуват, а ПИК на НОИ/НАП най-вероятно ще бъде закрит като система. За да може да има алтернатива на СМС и да не зависи достъпа към е-услуги от достъп до телефонен номер.
Благодаря Ви!
Електронната идентификация, чрез мобилно устройство би трябвало да може да работи и без наличие на интернет, както и да се използа за идентификация на гражданин използващ друго устройство за достъп до интернет, а не мобилното устройство с инсталираното и активирано приложение за eID.
Хипотетичен сценарий: Имаме активиран мобилен телефон с електронна идентификация, без мобилен интернет и WIFI. Имаме и наличен десктоп компютър с LAN достъп до интернет и липса на безжична комуникация. Потребителя би трябвало, използвайки мобилното си устройство да може да се идентифицира пред органите на държава, използвайки стационарния компютър и неговия браузър.
Възможност решение на горния проблем е мобилното устройство (приложението за eID) да генерира еднократен токън или нещо друго, което да може да се използва за идентификация на потребителя.
Електронната идентификация, чрез мобилно устройство би трябвало да може да работи и без наличие на интернет, както и да се използа за идентификация на гражданин използващ друго устройство за достъп до интернет, а не мобилното устройство с инсталираното и активирано приложение за eID.
Хипотетичен сценарий: Имаме активиран мобилен телефон с електронна идентификация, без мобилен интернет и WIFI. Имаме и наличен десктоп компютър с LAN достъп до интернет и липса на безжична комуникация. Потребителя би трябвало, използвайки мобилното си устройство да може да се идентифицира пред органите на държава, използвайки стационарния компютър и неговия браузър.
Възможност решение на горния проблем е мобилното устройство (приложението за eID) да генерира еднократен токън или нещо друго, което да може да се използва за идентификация на потребителя.
18.02.2022
04.03.2022
---
Справка или съобщение.---
Окончателен акт на Министерския съвет
Предлагам поддръжка на функционалност за валидация чрез автоматични (и понякога подвижни, т.е. без фиксиран адрес) валидатори.
Автоматични валидатори са устройства (технически средства), които могат да извършват автоматична валидация на идентичност, по QR код, презентиран от мобилното приложение на лицето, което иска да се идентифицира, без наличие на оператор (човек) обслужващ процеса на валидация.
Бизнес приложение на подобна услуга на BGID – идентификация на физически лица на киоски (например за плащане на сметки), пътуване в обществен транспорт чрез устройства за автоматична валидация на превозни документи и други.
Възможен начин на работа и модел за реализация:
-необходимо ниво на идентификация „ниско“ до "значително"
-мобилното приложение BGID генерира при поискване от потребител криптиран QR Код за автоматична валидация, който съдържа токен, издаден от сървърната част на системата за идентификация. По този токен, и други атрибути, които може да са носени в QR, или в сървъра на BGID, валидаторът може да извършва офлайн или онлайн проверка на лични данни чрез обръщение към API на BGID.
-примерно приложение - токенът може да идентифицира пътник в обществен транспорт, които (анонимно или не за превозвача), може да притежава “сметка” в системите на превозвача, асоциирана с токена, с която са свързани превозни документи - било то предварително закупени, или налични с отложено плащане. По този начин BGID приложението може да се ползва за пътуване в обществения транспорт, а и в редица други ситуации. Подобен механизъм е добър за по-добро опазване на лични данни, например за несподеляне с транспортния оператор на информация за правоимане (например преференция при пътуване за студент, ученик, пенсионер и др.) и лични данни на лице, имащо право на преференциално пътуване, а само, чрез достъп до съответен регистър, удостоверяване на наличието на право на преференция, оставайки потребителят анонимен за транспортния оператор.
-правата на валидаторите за наличния набор от лични данни могат да се определят на база на договорени отношения с доставчика на услугите, ползващи автоматична валидация.
Предлагам поддръжка на функционалност за валидация чрез автоматични (и понякога подвижни, т.е. без фиксиран адрес) валидатори.
Автоматични валидатори са устройства (технически средства), които могат да извършват автоматична валидация на идентичност, по QR код, презентиран от мобилното приложение на лицето, което иска да се идентифицира, без наличие на оператор (човек) обслужващ процеса на валидация.
Бизнес приложение на подобна услуга на BGID – идентификация на физически лица на киоски (например за плащане на сметки), пътуване в обществен транспорт чрез устройства за автоматична валидация на превозни документи и други.
Възможен начин на работа и модел за реализация:
-необходимо ниво на идентификация „ниско“ до "значително"
-мобилното приложение BGID генерира при поискване от потребител криптиран QR Код за автоматична валидация, който съдържа токен, издаден от сървърната част на системата за идентификация. По този токен, и други атрибути, които може да са носени в QR, или в сървъра на BGID, валидаторът може да извършва офлайн или онлайн проверка на лични данни чрез обръщение към API на BGID.
-примерно приложение - токенът може да идентифицира пътник в обществен транспорт, които (анонимно или не за превозвача), може да притежава “сметка” в системите на превозвача, асоциирана с токена, с която са свързани превозни документи - било то предварително закупени, или налични с отложено плащане. По този начин BGID приложението може да се ползва за пътуване в обществения транспорт, а и в редица други ситуации. Подобен механизъм е добър за по-добро опазване на лични данни, например за несподеляне с транспортния оператор на информация за правоимане (например преференция при пътуване за студент, ученик, пенсионер и др.) и лични данни на лице, имащо право на преференциално пътуване, а само, чрез достъп до съответен регистър, удостоверяване на наличието на право на преференция, оставайки потребителят анонимен за транспортния оператор.
-правата на валидаторите за наличния набор от лични данни могат да се определят на база на договорени отношения с доставчика на услугите, ползващи автоматична валидация.