Дія.Підпис і Smart ID

Ключ користувача лежить не у файлі, а в застосунку: Дія або Приват24. Людина сканує QR, підтверджує дію на телефоні — і ви отримуєте той самий CAdES-підпис, що й від файлового ключа. Ані пароля, ані файла.

Обидва надавачі підключаються одним параметром до тих самих віджетів sign і auth:

const signer = await embed('sign', { providers: ['file', 'diia', 'smartid'] });

Склад і порядок задаєте ви. Хочете лише Дію — передайте ['diia'], і перемикача взагалі не буде.

Головне: документ нікуди не йде

До надавача передається тільки геш — 32 байти. Сам файл не покидає пристрій користувача навіть у хмарному режимі: віджет рахує відбиток у себе в iframe і надсилає лише його.

документ ──▶ [ваш браузер: WASM-ядро] ──▶ геш (32 байти) ──▶ надавач
   │                                                            │
   └──── лишається у вас ◀──── підпис ◀──────────────────────────┘

Тому хмарний підпис не змінює вашої моделі приватності: сервіс, який ви підключаєте, не бачить ні змісту документа, ні його назви — лише відбиток.

Чим два надавачі відрізняються

Остання відмінність важлива для вашої моделі загроз. Smart ID працює напряму: сесія шифрується в браузері користувача, і наш бекенд у обміні не бере участі взагалі — через нього проходить лише малювання QR-картинки з несекретного посилання. Дія інакше: підпис надсилає застосунок на зареєстрований у ДП Дія ендпоінт, тобто на наш сервер, звідки віджет його забирає.

Геш обирати не треба

Кожен надавач приймає свій алгоритм гешу, і віджет підставляє потрібний сам — за обраним способом. Якщо ви передасте digest явно, для хмарного способу він буде проігнорований: інакше надавач просто відхилив би запит.

Пачка файлів — одна дія користувача

Кілька документів підписуються однією сесією: один QR, одне підтвердження в застосунку — і пачка підписів назад.

const { batch } = await signer.signBatch([file1, file2, file3]);

Кожен файл у пачці може впасти окремо, не валячи решту: у результаті буде { fileName, signature } для вдалих і { fileName, error } для решти.

Detached чи з даними

Надавач підписує геш, тож фізично повертає відокремлений (detached) підпис. За замовчуванням віджет вкладає у нього ваш документ і віддає повноцінний .p7s — значення підпису при цьому не змінюється. Потрібен саме detached — передайте { detached: true }.

Що бачить користувач у застосунку

Назву організації, адресу й призначення операції надавач бере зі свого боку — з даних, які ви вказали під час підключення. У самому запиті на підпис цього немає, тож змінити напис із коду не можна.

Для Дії це три різні поля: назва та повна назва юрособи задаються на відділенні, а рядок операції — це назва офера. Для входу Дія просить назву за шаблоном «Авторизація в "Назва вашої платформи"». Врахуйте, що офер не редагується: щоб змінити цей рядок, створюють новий офер і перемикають на нього налаштування.

Обмеження, про які варто знати заздалегідь

• QR живе 3 хвилини і одноразовий. Не встиг — починаєте спочатку; це обмеження надавачів, не наше.
• Хмарний підпис витрачає наш партнерський акаунт у надавача, тож на відміну від файлового ключа він доступний лише оплаченим доменам. Домени на автотріалі за замовчуванням не пускаються: заголовок Origin легко підробити, і будь-хто міг би нескінченно брати нові квоти за наш рахунок.
• Тестове середовище Дії потребує тестового застосунку (Android — App Tester, iOS — TestFlight). Бойовий застосунок з пісочницею не працює.

Вхід за КЕП тими самими способами

Обидва надавачі вміють не лише підписувати, а й підтверджувати особу — див. Вхід за КЕП. Віджет той самий, параметр той самий:

const auth = await embed('auth', { providers: ['file', 'diia', 'smartid'] });