Цифровые удостоверения и Passkeys: сходства и различия

• 🔑 Passkeys: для безопасного входа. Они доказывают, кто вы (аутентификация), и эффективно борются с фишингом.
• 📄 Цифровые удостоверения: для верифицируемого подтверждения. Они доказывают факты о вас (аттестация, например, ваше удостоверение личности, навыки), и вы контролируете, какая информация передается.
• 🤝 Что у них общего: Обе технологии используют надежную криптографию для повышения безопасности и улучшения пользовательского опыта по сравнению с паролями.
• 🎯 Чем они отличаются: Passkeys в основном предназначены для доступа к сервисам. Цифровые удостоверения — для предоставления проверенной информации о себе.

Цифровой мир быстро меняется. Эти изменения происходят не только потому, что традиционные пароли и общие секреты постоянно дают сбои, но и потому, что атаки, такие как фишинг и дипфейки на основе ИИ, становятся все более изощренными и их сложнее обнаружить. Эти продвинутые угрозы могут обмануть даже осторожных пользователей и сделать старые способы проверки личности ненадежными. Это ясно показывает, что цифровое криптографическое доказательство — единственный по-настоящему безопасный способ подтвердить личность. В этой сложной ситуации нам срочно нужны более безопасные, удобные и криптографически верифицируемые способы взаимодействия в интернете. Эта потребность вывела на передний план две ключевые технологии: Passkeys, которые уже широко используются, и цифровые удостоверения, которые только начинают свой путь. Эти технологии полагаются не на утверждения, проверяемые человеком, которые все легче подделать, а на машинно-проверяемое криптографическое доказательство для построения настоящего доверия.

В 2023-2025 годах использование Passkeys значительно возросло благодаря мощной поддержке со стороны крупных компаний, таких как Apple, Google и Microsoft, а также FIDO Alliance. Основанные на надежном стандарте W3C WebAuthn, Passkeys представляют собой фундаментальный отход от слабых, общих секретов. Вместо паролей они используют криптографию с открытым ключом. В этом случае закрытый ключ, безопасно хранящийся на устройстве пользователя, подписывает запросы-вызовы от доверяющей стороны (RP). Это доказывает, что у пользователя есть ключ, не раскрывая сам ключ.

Эта криптография делает Passkeys очень устойчивыми к фишингу — это большой плюс, поскольку фишинговые атаки становятся все хитрее, иногда используя дипфейки для большей реалистичности. Поскольку Passkey привязан к конкретному веб-сайту или приложению, для которого он был создан, пользователи не могут случайно использовать его на поддельных сайтах. Это распространенная проблема старых методов входа, уязвимых для таких продвинутых уловок. Passkeys также предотвращают повторное использование паролей и риски атак с подстановкой учетных данных после утечек данных. Помимо безопасности, Passkeys значительно улучшают процесс входа: он становится быстрее, часто требуя лишь биометрического сканирования (например, Face ID или отпечатка пальца), поэтому пользователям не нужно запоминать или вводить длинные пароли. Такое сочетание повышенной безопасности и простоты использования обеспечило им быструю популярность.

В то же время цифровые удостоверения, часто хранимые в цифровых идентификационных кошельках, стали гораздо более обсуждаемой темой. Хорошим примером этой тенденции является кошелек цифровой идентификации ЕС (EUDI Wallet).

В отличие от Passkeys, которые в основном предназначены для аутентификации (доказательства того, кто вы, демонстрируя контроль над закрытым ключом), цифровые удостоверения (основанные на стандартах, таких как W3C Verifiable Credentials (VC) или ISO mdocs) связаны с криптографически верифицируемой аттестацией (доказательством того, что является правдой о вас, с помощью заявлений с цифровой подписью). Возможность надежно проверять эти заявления важна, особенно сейчас, когда дипфейки могут создавать убедительные подделки традиционных доказательств. Без криптографических проверок даже экспертам бывает трудно отличить настоящее от подделки. Они позволяют людям в цифровом виде носить и предъявлять проверенную информацию — например, имя, дату рождения, водительские права, образование или профессиональные сертификаты — способом, который является криптографически безопасным, уважает конфиденциальность (позволяя пользователям делиться только необходимой информацией) и может быть проверен машинами.

Рост популярности обеих этих технологий не случаен. Он отражает более широкий сдвиг в отрасли от централизованных систем идентификации на основе паролей к более децентрализованной, ориентированной на пользователя модели, построенной на криптографическом доверии. Пароли — известное слабое место в онлайн-безопасности. Старые способы обмена идентификационными данными часто неудобны, небезопасны или передают слишком много данных, нанося вред конфиденциальности пользователей. Passkeys напрямую устраняют уязвимость аутентификации. Цифровые удостоверения решают проблему безопасного обмена атрибутами с контролем со стороны пользователя. Обе технологии используют схожую криптографию и все больше зависят от интеграции с платформами и безопасного оборудования, что свидетельствует о совместных усилиях по значительному улучшению наших систем цифровой идентификации.

Хотя Passkeys отвечают за «вход в систему», а цифровые удостоверения — за «подтверждение атрибутов», они используют схожие криптографические основы и играют взаимодополняющие роли в создании доверенных цифровых взаимодействий. Это то, что нам действительно нужно, поскольку современные угрозы, такие как изощренный фишинг и дипфейки, делают старые, некриптографические способы проверки личности небезопасными. Это подводит нас к главному вопросу: как связаны Passkeys и цифровые удостоверения, и как они могут работать вместе в повседневных пользовательских ситуациях?

В этой статье мы исследуем эту синергию. Мы рассмотрим их различия и сходства, протоколы, которые их обеспечивают, их общую зависимость от безопасного оборудования и то, как они могут взаимодействовать в таких сценариях, как регистрация пользователя, вход с повышенной аутентификацией и миграция устройств. Мы также затронем, как новые стандарты браузеров, такие как Digital Credentials API, стремятся соединить эти миры. Эта статья фокусируется именно на взаимодействии между этими технологиями, дополняя более глубокое техническое исследование Digital Credentials API, которое уже доступно.

Чтобы понять, как Passkeys и цифровые удостоверения могут работать вместе, важно сначала уяснить их отличительные характеристики и технологические уровни, которые лежат в их основе.

Следующая таблица представляет собой высокоуровневое сравнение:

Это сравнение показывает, что, хотя обе технологии используют криптографию для обеспечения доверия, их основные функции и типичные сценарии использования значительно различаются. Passkeys оптимизированы для частой и безопасной аутентификации, в то время как цифровые удостоверения превосходно справляются с предоставлением верифицируемых атрибутов с согласия пользователя.

Passkeys реализуются через взаимодействие нескольких ключевых стандартов:

• WebAuthn (Web Authentication): Этот стандарт W3C определяет JavaScript API, который веб-приложения используют для взаимодействия с аутентификаторами для регистрации (navigator.credentials.create()) и аутентификации (navigator.credentials.get()) Passkeys. Он действует как мост между веб-приложением доверяющей стороны и браузером или операционной системой пользователя. WebAuthn расширяет общий Credential Management API от W3C.

• CTAP (Client to Authenticator Protocol): Определенный FIDO Alliance, CTAP специфицирует, как клиент (браузер или ОС) взаимодействует с устройством-аутентификатором. Это может быть платформенный аутентификатор, встроенный в устройство (использующий безопасное оборудование, такое как TPM или Secure Enclave), или перемещаемый аутентификатор, такой как USB-ключ безопасности или даже телефон, выступающий в роли аутентификатора для другого устройства. CTAP2 — это версия, согласованная с FIDO2 и Passkeys, поддерживающая различные транспорты, такие как USB, NFC и Bluetooth Low Energy (BLE).

• Расширенные сигналы доверия и привязка к устройству (соображения для синхронизированных Passkeys): По мере того как Passkeys эволюционировали и стали синхронизируемыми между устройствами («учетные данные для нескольких устройств»), доверяющим сторонам (RP) иногда требовалось идентифицировать конкретное физическое устройство, используемое во время аутентификации, для оценки рисков. Ранние идеи, такие как расширения devicePubKey и supplementalPubKeys, пытались решить эту проблему, но позже от них отказались. Рабочая группа по сигналам доверия FIDO Alliance сейчас разрабатывает им замену. Основная идея заключается в том, что аутентификатор с синхронизированным Passkey мог бы также создавать и использовать вторую пару ключей, привязанную к устройству. Во время аутентификации аутентификатор мог бы предоставлять подписи как от основного синхронизированного ключа, так и от этого второго, привязанного к устройству ключа. Это позволило бы RP распознавать конкретное доверенное устройство. Это могло бы означать меньше сложностей (например, пропуск дополнительных проверок), даже если основной Passkey синхронизирован на многих устройствах, и все это без потери главного преимущества синхронизированных Passkeys: удобства использования на разных устройствах. Хотя окончательного стандарта для этого еще нет, такая функция удовлетворила бы ключевую потребность RP, требующих высокого уровня гарантий, позволяя им лучше обнаруживать использование нового устройства или соответствовать внутренним правилам строгой аутентификации клиента (SCA).

Аналогично, экосистема цифровых удостоверений опирается на набор протоколов и новых API для своего функционирования:

• Digital Credentials API: Это разрабатываемая спецификация W3C, направленная на расширение API navigator.credentials.get() для того, чтобы веб-приложения могли запрашивать верифицируемые учетные данные из цифрового кошелька пользователя стандартизированным способом. Он служит той же цели, что и WebAuthn, но фокусируется на VC, а не на Passkeys.
• OpenID for Verifiable Presentations (OpenID4VP): Этот протокол, построенный на OAuth 2.0, определяет, как верификатор (RP, запрашивающий удостоверения) может запрашивать VC из кошелька владельца. Ключевые элементы включают presentation_definition (указывающий требуемые удостоверения и заявления), кошелек, действующий как сервер авторизации, и vp_token, передающий верифицируемое представление обратно верификатору.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): Дополняя OpenID4VP, этот стандарт унифицирует, как издатель доставляет VC в кошелек владельца, снова используя механизмы OAuth 2.0. Он включает такие концепции, как предложения удостоверений, потоки с предварительной авторизацией или кодом авторизации, и выделенные конечные точки для удостоверений.
• Стандарты ISO (например, ISO/IEC 18013-7, ISO/IEC 23220): Эти международные стандарты особенно важны для мобильных водительских удостоверений (mDL) и других типов мобильных документов (mdoc). ISO 18013-5 определяет основную структуру данных mDL и офлайн-предъявление (NFC, BLE), в то время как ISO 18013-7 и 23220 специфицируют механизмы онлайн-предъявления, включая REST API и профили интеграции с OpenID4VP (Приложение B к 18013-7). Платформы, такие как Google Wallet и Apple Wallet, используют эти стандарты ISO.

Несмотря на разные цели и протоколы, Passkeys и цифровые удостоверения имеют общие фундаментальные строительные блоки:

• Асимметричная криптография: Обе технологии в значительной степени полагаются на пары открытых-закрытых ключей. Passkeys используют закрытый ключ для доказательства владения во время аутентификации. Цифровые удостоверения используют закрытый ключ издателя для подписи удостоверения, обеспечивая его подлинность и целостность, а владелец может использовать свой закрытый ключ для подписи представления, содержащего удостоверение.
• Безопасное оборудование: Защита закрытых ключей имеет первостепенное значение. Обе технологии извлекают огромную пользу из компонентов безопасного оборудования, интегрированных в современные устройства:
  • TPM (Trusted Platform Module): Выделенный чип, часто встречающийся в ноутбуках и настольных компьютерах, обеспечивающий безопасную генерацию ключей, их хранение и криптографические операции. Он обычно используется платформенными аутентификаторами, такими как Windows Hello.
  • Secure Enclave: Аппаратный менеджер ключей от Apple, изолированный от основного процессора на iPhone, iPad и Mac, используемый для защиты конфиденциальных данных, включая закрытые ключи Passkeys.
  • Android Keystore System / StrongBox Keymaster: Android предоставляет аппаратно-защищенное хранилище ключей (Keystore), часто реализованное с использованием выделенного безопасного процессора (StrongBox Keymaster), предлагая надежную защиту для криптографических ключей на устройствах Android. Хотя некоторые менеджеры паролей используют название «Strongbox», ключевым элементом здесь является базовый безопасный аппаратный компонент, предоставляемый ОС.

Использование одних и тех же безопасных аппаратных элементов (TPM, Secure Enclave, аппаратно-защищенное хранилище ключей Android) как для операций с Passkeys, так и потенциально для защиты закрытых ключей в цифровых кошельках создает значительную синергию. Платформам не нужны отдельные безопасные чипы для каждой функции. Вместо этого они могут использовать единую, надежную аппаратную базу и связанные с ней API операционной системы (например, для хранилища ключей Android или Secure Enclave от Apple) для надежной защиты как аутентификационных учетных данных (Passkeys), так и аттестационных учетных данных (VC). Это упрощает разработку, повышает согласованность безопасности и эффективно использует существующие инвестиции в платформу.

Более того, Credential Management API браузера (navigator.credentials) является ключевым организующим уровнем. Сначала расширенный WebAuthn для Passkeys, теперь он дополнительно расширяется Digital Credentials API для VC. Это указывает на четкий план: предоставить RP один основной способ запрашивать различные учетные данные и дать пользователям знакомый способ их выбора (например, через менеджер учетных данных Android или встроенные менеджеры паролей браузера). Это скроет сложные технические детали протоколов, таких как CTAP, OID4VP и ISO, упрощая жизнь разработчикам и пользователям.

С точки зрения доверяющей стороны (RP), понимание того, как эффективно интегрировать и использовать Passkeys и цифровые удостоверения, имеет решающее значение для повышения безопасности, улучшения пользовательского опыта и соответствия нормативным требованиям. В этом разделе анализируется, как RP могут развертывать эти технологии в различных распространенных сценариях и экосистемах.

Оптимальная стратегия интеграции Passkeys и цифровых удостоверений значительно варьируется в зависимости от конкретного варианта использования и связанных с ним профиля риска и требований. Следующая таблица представляет собой высокоуровневое сравнение по распространенным сценариям:

Сравнение сценариев экосистем

Легенда:

• Роль VC 🆔: Описывает роль во время основного взаимодействия, признавая, что VC часто используются для первоначальной регистрации/KYC во всех сценариях.
• Привязка к устройству? 🔗: Относится к необходимости явной привязки к устройству помимо стандартной привязки Passkey к источнику, что особенно актуально для синхронизированных Passkeys.
• Требования к кошельку EUDI в ЕС*: Этот сценарий отражает требования будущего регламента eIDAS 2, который, как ожидается, вступит в силу примерно через 36 месяцев после окончательного введения в действие имплементирующих актов (вероятно, в конце 2020-х годов).

Это сравнение дает краткий обзор; в следующих разделах мы углубимся в специфику каждого сценария с точки зрения интеграции для RP.

• Цель: Быстрый, беспрепятственный доступ с хорошим базовым уровнем безопасности.
• Вероятный сценарий:
  • Основная аутентификация: Passkeys будут доминировать. Их устойчивость к фишингу и безупречный UX (часто просто биометрия/PIN) делают их идеальными для замены паролей в сценариях частого входа.
  • Роль цифровых удостоверений: Минимальная для основного входа. VC могут использоваться опционально после входа для конкретных действий, таких как проверка возраста (например, при покупке товаров с ограничениями), персонализация на основе проверенных атрибутов (например, статус лояльности) или ускоренное заполнение профиля при первоначальной регистрации.
• Взаимодействие: Passkey обрабатывает основной вход; VC зарезервированы для опциональных взаимодействий на основе атрибутов.

• Цель: Высокий уровень гарантии при входе и, при необходимости, верифицированное утверждение личности.
• Вероятный сценарий:
  • Passkeys как самодостаточный 2FA/MFA: Passkeys по своей сути соответствуют требованиям двухфакторной аутентификации, когда проверка пользователя (PIN/биометрия) происходит во время церемонии входа. Они сочетают в себе:
    • Владение: Доказательство контроля над закрытым ключом.
    • Знание/Неотъемлемость: Проверка пользователя через PIN или биометрию. Это делает сам вход с Passkey сильным, устойчивым к фишингу методом MFA, достаточным для многих сценариев с высоким уровнем гарантии без необходимости отдельного второго шага только для достижения 2FA.
  • Повышение уровня для проверки личности (однократно): Основная потребность в дополнительном шаге с цифровыми удостоверениями возникает, когда сервису необходимо явно проверить личность, а не просто аутентифицировать вернувшегося пользователя. Такая надежная криптографическая проверка жизненно важна, когда дипфейки могут убедительно подделывать визуальные или документальные удостоверения личности. Только цифровое криптографическое доказательство из доверенного источника может надежно подтвердить атрибут. Это может потребоваться:
    • Во время первоначальной регистрации.
    • Для конкретных высокорисковых действий, требующих подтвержденных атрибутов личности. В этих случаях RP запрашивает предъявление конкретного верифицируемого удостоверения (например, PID, национального удостоверения личности) из кошелька пользователя после входа с Passkey.
  • Идентификация для восстановления: Как только личность пользователя была надежно подтверждена (например, через шаг предъявления VC), эта проверенная информация о личности потенциально может быть использована в безопасных процедурах восстановления аккаунта. Например, если пользователь теряет все свои аутентификаторы Passkey, предъявление удостоверения личности с высоким уровнем гарантии может стать частью процесса восстановления доступа и регистрации новых Passkeys.
• Взаимодействие: Passkeys обеспечивают надежную, самодостаточную 2FA/MFA для аутентификации. VC используются стратегически для явной проверки личности, когда это требуется, и эта проверенная личность также может поддерживать безопасные механизмы восстановления аккаунта.

• Цель: Оптимизированное, безопасное оформление заказа или инициация платежа, минимизируя неудобства для пользователя.
• Вероятный сценарий:
  • Аутентификация для оплаты: Passkeys идеально подходят для аутентификации пользователя в его аккаунте поставщика платежных услуг (PSP) (например, PayPal) или непосредственно в процессе оформления заказа у продавца. Это заменяет пароли и обеспечивает быстрое, безопасное подтверждение для инициации платежа.
  • Регистрация/KYC: VC остаются критически важными на этапе регистрации или настройки аккаунта у PSP или продавца, предоставляя проверенную информацию о личности (проверки KYC/AML), необходимую для включения возможностей оплаты.
  • Проблемы с трением при транзакциях: Введение отдельного шага предъявления верифицируемого удостоверения во время основного процесса авторизации платежа (требующего взаимодействия с цифровым идентификационным кошельком) добавило бы значительное трение по сравнению с бесшовным шагом подтверждения с помощью Passkey. Такое нарушение пользовательского опыта, вероятно, повредит коэффициентам конверсии и поэтому не подходит для типичных сценариев оплаты с низким уровнем трения.
• Взаимодействие: Passkey обеспечивает безопасность аутентификации для самого акта оплаты. VC обрабатывают необходимую, часто однократную, проверку личности/KYC, требуемую для создания платежного аккаунта, но не участвуют в критически важном, чувствительном к трению шаге подтверждения платежа. (Сложная тема использования цифровых удостоверений непосредственно в качестве платежных инструментов, включая то, как различные типы кошельков и новые API браузеров могут обеспечивать или взаимодействовать с такими специфичными для платежей VC, подробно рассматривается в нашей предстоящей дополнительной статье: Цифровые удостоверения и платежи).

• Цель: Безопасный доступ к банковским услугам со значительным снижением мошенничества, особенно связанного с фишингом, путем перехода от устаревших методов аутентификации.
• Вероятный сценарий:
  • Замена устаревшей MFA: Многие финансовые учреждения в настоящее время полагаются на пароли в сочетании с уязвимыми для фишинга вторыми факторами, такими как SMS OTP. Passkeys предлагают значительно превосходящую альтернативу, обеспечивая сильную аутентификацию, которая по своей сути устойчива к фишингу, в одном действии пользователя.
  • Основной вход с помощью Passkeys: Внедрение Passkeys для основного входа немедленно повышает безопасность благодаря их устойчивости к фишингу. Криптографическая природа Passkeys смягчает наиболее распространенные векторы атак, которые преследуют традиционные учетные данные.
  • Повышение уровня на основе рисков - Тщательное рассмотрение сигналов устройства: Для операций с более высоким риском (например, крупные переводы, изменение контактных данных) финансовые учреждения могут рассмотреть возможность повышения уровня верификации. Хотя сигналы привязки к устройству, связанные с Passkeys, являются вариантом, их необходимость следует тщательно оценивать. Устойчивость к фишингу основной аутентификации с помощью Passkey сама по себе значительно снижает многие риски.
  • Безопасность, основанная на результатах, и снижение мошенничества: Значительное снижение риска фишинга, достигаемое с помощью Passkeys, является критическим фактором. Подход к безопасности, основанный на результатах, с акцентом на надежность и устойчивость к фишингу метода аутентификации, может привести к существенному сокращению мошенничества. Вес устойчивого к фишингу фактора, такого как Passkey, значительно выше, чем добавление большего количества уязвимых для фишинга факторов. Это должно быть центральным элементом стратегии финансового учреждения при переходе от старых методов.
  • VC для регистрации/подтверждения личности: Как и в других сценариях, VC остаются необходимыми для надежной первоначальной проверки KYC/AML и для безопасного обновления данных о личности клиента с использованием проверенной информации, создавая надежную основу для банковских отношений.
• Взаимодействие: Passkeys служат мощным, устойчивым к фишингу основным методом аутентификации, кардинально снижая риск мошенничества по сравнению с устаревшими системами. Сигналы устройства для повышения уровня являются тактическим вариантом. Внутренняя надежность Passkeys должна лежать в основе подхода к безопасности, основанного на рисках, потенциально снижая чрезмерную зависимость от дополнительных, менее устойчивых к фишингу факторов. VC обеспечивают фундаментальную гарантию личности.

• Цель: Соответствовать регламенту eIDAS 2 (статья 5f), требующему принятия кошелька цифровой идентификации ЕС определенными доверяющими сторонами (государственные органы, крупные частные организации в регулируемых секторах, VLOP), обеспечивая как псевдонимный вход с сохранением конфиденциальности, так и высоконадежную проверку личности/атрибутов, когда это требуется по закону.
• Вероятный сценарий:
  • Псевдонимный вход (по умолчанию): Пользователь инициирует вход. RP запрашивает аутентификацию через кошелек EUDI. Кошелек использует свой встроенный «псевдонимный ключ» — аппаратно-привязанный, привязанный к RP постоянный ключ WebAuthn, хранящийся в сертифицированном защищенном элементе устройства (WSCD) — для аутентификации пользователя. Это обеспечивает сильную, соответствующую SCA аутентификацию (владение + проверка пользователя), сохраняя при этом гражданскую личность пользователя псевдонимной по умолчанию.
  • Повышение уровня для идентификации/атрибутов (требуется по закону): Только если у RP есть конкретное юридическое основание в соответствии с законодательством Союза или национальным законодательством (например, PSD2, AML, регистрация в сфере телекоммуникаций) требовать проверки личности или конкретных атрибутов, он инициирует второй шаг. RP запрашивает представление (через OpenID4VP) необходимых данных для идентификации личности (PID) или квалифицированного подтверждения атрибутов (QAA) из кошелька. Пользователь должен явно дать согласие на передачу этих идентифицированных данных.
  • Аутентификация кошелька и RP: Процесс включает взаимную аутентификацию. RP аутентифицирует себя перед кошельком (на основе своей официальной регистрации), а кошелек подтверждает свою подлинность и действительность удостоверения перед RP, используя безопасное оборудование (WSCD) и связанную с ним сертификационную инфраструктуру.
• Взаимодействие: Кошелек EUDI действует как единый аутентификатор. Его интегрированный Passkey WebAuthn (псевдонимный ключ) обрабатывает стандартный вход, предлагая сильную, сохраняющую конфиденциальность аутентификацию. Возможности VC кошелька используются выборочно для явного, законодательно установленного раскрытия личности или атрибутов, обеспечивая минимизацию данных по умолчанию.

Навигация в этом развивающемся ландшафте требует стратегического планирования. Вот ключевые соображения для доверяющих сторон (RP).

Для RP основным действием сегодня должно быть включение и поощрение использования Passkeys для аутентификации. Passkeys стандартизированы, широко поддерживаются платформами и предлагают немедленные, большие преимущества в безопасности (устойчивость к фишингу) и пользовательском опыте (более быстрый и простой вход). Это означает меньшую зависимость от паролей и небезопасных методов MFA, таких как SMS OTP. Это также может снизить затраты на поддержку, связанные со сбросом паролей и восстановлением аккаунтов. Стремление к широкому использованию Passkeys создает современную, безопасную основу для аутентификации пользователей. Хотя внедрение поначалу может быть медленным, обучение пользователей преимуществам и упрощение регистрации могут помочь им начать.

Хотя сами Passkeys представляют собой значительный шаг к надежной аутентификации и могут соответствовать требованиям строгой аутентификации клиента (SCA), некоторые организации могут иметь внутренние рамки соответствия с еще более строгими интерпретациями или конкретными опасениями, особенно в отношении синхронизированных Passkeys. Для доверяющих сторон (RP), сталкивающихся с такими сценариями, где отделы комплаенса ищут дополнительные гарантии, полезно знать, что дополнительные меры могут дополнять развертывание Passkeys. Они могут помочь устранить предполагаемые пробелы в соответствии с SCA или удовлетворить эти повышенные внутренние требования. Одной из распространенных стратегий является использование сигналов доверия устройства, подход, применяемый такими сервисами, как PayPal.

PayPal, например, позволяет пользователям помечать устройство как «запомненное», как описано на их справочной странице:

Это означает, что если пользователь входит в систему со своим паролем (то, что он знает) с запомненного устройства (то, что у него есть), PayPal может считать это достаточным для SCA во многих случаях. Однако они также заявляют: «Могут быть случаи, когда мы все равно попросим вас о дополнительной проверке, чтобы убедиться, что ваш аккаунт в безопасности». Это может включать отправку одноразового кода через SMS или запрос подтверждения через приложение PayPal.

Этот подход обеспечивает более плавный пользовательский опыт на доверенных устройствах, при этом предоставляя механизмы для повышенной аутентификации, когда риски выше или этого требуют нормативные акты. RP могут рассмотреть аналогичные модели, где комбинация основной аутентификации (например, Passkey) и доверия к устройству (потенциально управляемого вне прямых механизмов WebAuthn, если это необходимо) может помочь устранить пробелы в соответствии с SCA. Однако для более интегрированного и стандартизированного подхода к сигналам доверия, специфичным для устройства, в рамках самой структуры WebAuthn, внимание обращается на текущие разработки в этой области.

Что касается таких интегрированных с WebAuthn подходов для более сильного доверия к устройству, RP в средах с высоким уровнем безопасности должны понимать историю и будущее направление. Прошлые предложения по расширениям WebAuthn, такие как devicePubKey и supplementalPubKeys, были направлены на предоставление этих специфичных для устройства сигналов доверия. Это были попытки решить проблемы безопасности синхронизированных Passkeys, которые, предлагая критически важное удобство для массового внедрения, вводят иные профили риска (например, зависимость от восстановления облачного аккаунта) по сравнению с ключами, привязанными к устройству. Идея таких расширений заключалась в том, чтобы позволить RP получать дополнительный уровень гарантии, проверяя подпись от ключа, специально привязанного к используемому физическому устройству, даже когда сам основной Passkey синхронизирован.

Хотя эти конкретные расширения (devicePubKey и supplementalPubKeys) были прекращены, проблема получения более сильных сигналов привязки к устройству для синхронизированных Passkeys сохраняется. Поэтому RP должны следить за разработкой и стандартизацией последующих решений в этой области. Такие решения могли бы помочь RP лучше оценивать риск (например, отличать вход с известного, доверенного устройства от входа с нового синхронизированного) без принуждения всех пользователей использовать менее удобные Passkeys, привязанные к устройству. Этот контекст ставит перед RP более сложный выбор, чем просто «синхронизированные против привязанных к устройству». Синхронизированные Passkeys (обычно соответствующие AAL2) предлагают наибольшее удобство и лучшие шансы на внедрение, что жизненно важно для потребительских приложений. Passkeys, привязанные к устройству (возможно, AAL3), дают наивысший уровень гарантии, но могут быть сложнее в использовании. Целью прекращенных расширений было найти золотую середину — улучшить безопасность для синхронизированных ключей, добавив обратно специфичный для устройства сигнал доверия. Это могло бы помочь снизить некоторые риски в случае компрометации облачной синхронизации, не теряя при этом всего удобства синхронизации. Поэтому RP должны искать последующие решения, направленные на это. Лучшая стратегия будет зависеть от конкретной толерантности к риску RP, пользовательской базы и зрелости любых новых стандартов.

Помимо конкретных механизмов в WebAuthn для доверия к устройству, некоторые доверяющие стороны (RP) — особенно в таких секторах, как банковское дело, страхование и платежные услуги — начинают оценивать цифровые удостоверения (Verifiable Credentials, или VC) как дополнительный или даже следующий компонент в своих стратегиях идентификации и безопасности.

Значительным фактором, стимулирующим этот интерес, является надежная привязка к устройству, часто связанная с цифровыми удостоверениями, особенно когда они управляются в безопасных цифровых идентификационных кошельках. Эти кошельки могут использовать аппаратно-защищенную безопасность (например, Secure Enclaves или TPM) для защиты удостоверений и закрытых ключей, используемых для их предъявления. Издатели и поставщики кошельков также могут применять политики, которые делают определенные высокоценные удостоверения по своей сути привязанными к устройству, предлагая уровень контроля, привлекательный для сценариев с высоким уровнем гарантии.

Крайне важно признать, что, хотя эта улучшенная возможность привязки к устройству является убедительной особенностью для этих RP, основное назначение цифровых удостоверений (аттестация атрибутов и заявлений) отличается от назначения Passkeys (аутентификация пользователя). Passkeys подтверждают, кто является пользователем, в то время как цифровые удостоверения подтверждают, что является правдой о пользователе. Несмотря на это фундаментальное различие в назначении, сильные характеристики безопасности VC, хранящихся в кошельке, делают их областью активного рассмотрения для RP, стремящихся добавить дополнительные уровни гарантий. Это естественным образом подводит обсуждение к поставщикам этих цифровых идентификационных кошельков и экосистеме, которая обеспечивает выдачу, хранение и предъявление таких удостоверений.

В то время как Passkeys предлагают прямую аутентификацию, цифровые удостоверения (VC) управляются и предъявляются доверяющим сторонам через цифровые идентификационные кошельки. Эти кошельки, будь то нативные платформенные решения (например, Apple Wallet, Google Wallet) или сторонние приложения (например, кошелек EUDI), развиваются для использования новых стандартов браузеров, таких как Digital Credentials API, для более плавной онлайн-проверки личности (например, проверка возраста, обмен атрибутами цифрового ID).

Подробные механизмы различных типов кошельков, конкретные стратегии платформ для интеграции VC (включая фокус Apple на mDoc для взаимодействий с браузером в противовес более широкой поддержке OpenID4VP в Android через его Credential Manager), как эти кошельки облегчают аттестацию атрибутов, и совершенно отдельные соображения для любых платежных функциональностей являются сложными темами. Они подробно рассматриваются в нашей предстоящей дополнительной статье: Цифровые удостоверения и платежи.

Эта текущая статья сохраняет свой фокус на фундаментальном взаимодействии между Passkeys для аутентификации и общей роли цифровых удостоверений для аттестации атрибутов.

Passkeys и цифровые удостоверения, хотя и различаются по своему основному назначению, представляют собой два столпа современного, более безопасного и ориентированного на пользователя будущего цифровой идентификации. Понимание того, как они связаны и могут поддерживать друг друга, является ключом к созданию следующей волны онлайн-сервисов.

Исходя из текущего состояния и траектории развития этих технологий, для доверяющих сторон выделяются два ключевых действия:

• Внедряйте Passkeys повсеместно уже сегодня: Стандарты зрелые, поддержка платформ широка, а преимущества перед паролями очевидны и существенны. Сделайте Passkeys целевым методом аутентификации по умолчанию для повышения безопасности и удобства использования немедленно.
• Добавляйте повышение уровня через кошелек там, где важны AML/KYC: Для процессов, требующих более высокого уровня гарантии или конкретных проверенных атрибутов — таких как соответствие нормам по борьбе с отмыванием денег (AML) / знай своего клиента (KYC), выполнение надежной проверки возраста или подтверждение профессиональной квалификации — интегрируйте потоки предъявления верифицируемых удостоверений для получения криптографически верифицируемых атрибутов, которые незаменимы для доверия к личности и заявлениям в эпоху изощренных цифровых подделок и дипфейков. Используйте Digital Credentials API, где это возможно, но реализуйте надежные резервные варианты с QR/глубокими ссылками для обеспечения кросс-платформенного охвата до стабилизации API. Это обеспечивает целевую высокую гарантию, не обременяя каждый вход.

Заглядывая в будущее, мы можем ожидать большей конвергенции и улучшений:

• Улучшенная переносимость учетных данных: Методы передачи между устройствами, вероятно, станут лучше. Это может выйти за рамки кросс-девайсной аутентификации CTAP 2.2 для Passkeys и включить более плавные способы перемещения VC между кошельками, хотя стандартизация здесь еще не так далеко продвинулась.
• Консолидированные API браузеров: Digital Credentials API, вероятно, созреет и будет более последовательно поддерживаться в разных браузерах. Это предложит RP более стандартный способ запрашивать как Passkeys, так и VC через navigator.credentials.
• Единый пользовательский опыт: В конечном счете, пользователи должны видеть меньше технических различий между аутентификацией с помощью Passkey и предъявлением атрибутов с помощью VC. Платформенные менеджеры учетных данных и кошельки, вероятно, будут плавно управлять этими взаимодействиями за кулисами. Они будут использовать общие криптографические инструменты и безопасное оборудование, позволяя пользователям просто одобрять запросы с помощью знакомых биометрических или PIN-кодовых подсказок, независимо от того, используется ли Passkey или VC. Более того, концепции, такие как непрерывная пассивная аутентификация (CPA), которая постоянно проверяет пользователей в фоновом режиме с использованием поведенческой биометрии и других сигналов, могут еще больше усилить эту бесшовную безопасность, потенциально работая вместе с активными аутентификаторами, такими как Passkeys.

Достижение этого интегрированного будущего потребует дополнительной работы над стандартами, их поддержкой платформами и использованием приложениями. Используя Passkeys сейчас и вдумчиво добавляя цифровые удостоверения, организации могут быть готовы к этому переходу в цифровой мир, который будет беспарольным и даст пользователям больше контроля над своими данными.