[GOST2015-TEST] Будущее NCALayer - каковы планы на модули и поддерживаемые алгоритмы?

#1

Добрый день,

В последних версиях SDK появились тестовые модули NCALayer, а так же ссылки на пример (https://github.com/pkigovkz/NCALayerJSExample) и описание (https://github.com/pkigovkz/sdkinfo/wiki). Судя о всему, в новых модулях реализован новый модуль (я правильно это называю?) kz.gov.pki.knca.basics и в нем метод sign.

Таким образом мы сейчас имеем:

  • kz.gov.pki.knca.applet.Applet - старый модуль, вроде бы “deprecated”, но в интерфейсе pki.gov.kz все еще используется;
  • kz.gov.pki.knca.commonUtils - текущий модуль, используется повсеместно;
  • kz.gov.pki.knca.basics - видимо, новый модуль.

В связи с чем вопросы:

  1. Будут ли сохранены все эти модули?
  2. Если некоторые модули предполагается перестать распространять (отказаться от них, либо заблокировать или сделать с ними что-то еще), то когда?
  3. Какие из перечисленных модулей будут поддерживать какие алгоритмы?
#2

Здравсвтуйте!
В модуле может быть несколько сервисов. Модуль kz.gov.pki.knca.applet.knca_applet содержит сервис kz.gov.pki.knca.applet.Applet. В тестовой версии модуля добавили сервис kz.gov.pki.knca.basics. Основные возможности будут добавляться в рамках этого сервиса, есть планы перенести его в другой модуль после прекращения поддержки текущего модуля.

  1. knca_applet, commonUtils планируем убрать, как только реализуем необходимые функции.
  2. Хотелось бы, как мотивирующий факт для перехода, новый алгоритм сделать доступным только в новом модуле. Но скорее всего, не получится быстро отказаться, учитывая, что даже некоторые сервисы egov до сих пор не перешли на commonUtils.
  3. Пока планируем, что kz.gov.pki.knca.basics будет основным для всех алгоритмов. По commonUtils будем смотреть по ситуации.
#3

Добрый день,

Спасибо за ответы, но я был бы очень признателен если бы Вы пояснили как мы будем работать в июне с новыми алгоритмами в NCALayer. Времени осталось не очень много и всем нужно планировать.

Мое личное пожелание - чтобы можно было продолжать использовать все поддерживаемые НУЦ ключи и сертификаты через kz.gov.pki.knca.commonUtils.

Может быть я чего-то не понимаю, но особых преимуществ в kz.gov.pki.knca.basics ни для разработчиков, ни для пользователей я не заметил (разве что предполагаемая возможность получать метки времени, но для этого не обязательно новый сервис создавать). Расскажете про мотивацию для его разработки?

#4

Здравствуйте!
kz.gov.pki.knca.basics предлагает удобный интерфейс как для пользователя, так и для разработчика.

  1. Разработчику не нужно отдельно передавать тип хранилища, путь к файлу или название токена, при этом он может задавать ограничения по типу хранилища. Более удобный способ ограничения по типу сертификату и цепочке.
  2. Пользователь выбирает хранилище и конкретный ключ полностью в окне NCALayer. Ему отображается какой именно веб-ресурс просит подписать данные. В дальнейшем планируется добавить возможность просмотра данных, которые надо подписать. Не всем пользователям это может быть понятно, но будет полезной опцией.

Как выше писал, с commonUtils будем действовать по ситуации. И ситуация такова, что, скорее всего, поддержка нового алгоритма там добавится. Но новые возможности будут добавляться уже в basics.
Спасибо за обратный отзыв :slightly_smiling_face:

#5
  1. Разработчику не нужно отдельно передавать тип хранилища, путь к файлу или название токена, при этом он может задавать ограничения по типу хранилища. Более удобный способ ограничения по типу сертификату и цепочке.

Звучит хорошо, но, судя по документации (https://github.com/pkigovkz/sdkinfo/wiki/KNCA-Basics-Module#allowedstorages-обязательный), параметр allowedStorages является обязательным и в него нужно передать массив тех типов хранилищ, которые должны быть доступны пользователю. Таким образом если NCALayer начинает поддерживать новый тип хранилищ, опять нужно дорабатывать все информационные системы. Может быть стоит предусмотреть какой-то способ разрешить использовать все поддерживаемые типы носителей?

  1. Пользователь выбирает хранилище и конкретный ключ полностью в окне NCALayer. Ему отображается какой именно веб-ресурс просит подписать данные. В дальнейшем планируется добавить возможность просмотра данных, которые надо подписать. Не всем пользователям это может быть понятно, но будет полезной опцией.

И правда звучит хорошо, но не очень понятно зачем это делать в новом сервисе - можно было все то же самое реализовать в пользовательском интерфейсе вызовов kz.gov.pki.knca.commonUtils. Тогда разработчикам информационных систем не пришлось бы ничего переписывать. Ведь даже переход с kz.gov.pki.knca.applet.Applet на kz.gov.pki.knca.commonUtils превратился в бесконечный процесс конца которому не видать.

В дальнейшем планируется добавить возможность просмотра данных, которые надо подписать. Не всем пользователям это может быть понятно, но будет полезной опцией.

На самом деле вот это очень полезно! Двумя руками за!

#6

Да, по параметру allowedStorages, его уже сделали необязательным, если его не задавать, то по умолчанию будут доступны все хранилища. На следующей неделе обновим SDK.
На самом деле в планах есть вариант, обрабатывать вызовы commonUtils, переводя их в вызовы basics. commonUtils это всего лишь сервис, он может в любом модуле находиться. Таким образом функции commonUtils будут заморожены.

#7

Понятно, ждем обновления!