Кто выдал цифровой сертификат: зачем автоматизации проверяемые подтверждения

15 мая 2025 года W3C опубликовал семейство рекомендаций Verifiable Credentials 2.0 для проверяемых цифровых подтверждений. Они описывают машинную проверку происхождения и целостности утверждений. Это даёт повод посмотреть, что именно получает рабочая система, когда к заявке прикладывают сертификат или другое подтверждение.

Представим вымышленный учебный центр. Он выдал слушателю подтверждение прохождения курса. Позже документ поступил в другую организацию, где сотрудник перенёс сведения в карточку. Файл может выглядеть убедительно, но для автоматической обработки нужны понятные ответы: кто его выдал и к какому факту относятся сведения.

Кто участвует в проверке

В модели W3C есть издатель, держатель подтверждения и проверяющая сторона. Издатель делает утверждение, держатель предъявляет подтверждение, а получатель проверяет его происхождение и отсутствие изменений. В нашем учебном примере эти роли занимают центр, слушатель и организация, которой предъявлен документ.

У каждой стороны свой вопрос. Центру нужно корректно связать выданное подтверждение с событием обучения. Слушателю важно передать нужные сведения. Получателю требуется понять результат проверки и применить свои правила к полученному факту. Сам формат документа не решит, какой курс подходит для конкретной работы.

Предположим, организация принимает подтверждения только от определённых учебных центров. Тогда проверка целостности и решение о том, подходит ли издатель, будут разными шагами. Корректная подпись помогает установить происхождение утверждения. Оценка качества курса и его пригодности для должности остаётся отдельным решением.

Что вернётся в рабочую запись

Для условной карточки можно заранее определить небольшой набор сведений. Важен результат, который сотрудник сможет понять без повторного просмотра файла:

• Какое событие подтверждается: например, прохождение конкретного курса.
• Кто выдал подтверждение и какой результат дала техническая проверка.
• Принято ли подтверждение по правилам организации или требуется рассмотрение сотрудником.

Если проверка не завершилась из-за недоступного ресурса, полезно сохранить именно это состояние. Оно отличается от установленного нарушения целостности. Иначе техническая задержка может превратиться в неверную отметку о документе или его владельце.

В учебной проверке можно пройти один и тот же маршрут с корректным примером, изменённым содержимым и временно недоступной проверкой. Цель такого упражнения - увидеть, какие сведения попадут в карточку и какой следующий шаг останется сотруднику. Это собственный пример проверки процесса, а не результат испытаний W3C.

Стандарт даёт общий технический способ обмениваться проверяемыми утверждениями. Для рабочего процесса дополнительно нужны правила принятия результата, понятные состояния и место для ручного рассмотрения. Тогда подтверждение сможет участвовать в автоматизации как проверяемое сведение с известным происхождением.

Первоисточник: W3C, публикация Verifiable Credentials 2.0, 15 мая 2025 года

Источник: pro-automatization.ru