Цифровые учетные данные и платежи: стратегия Apple Wallet против Google Wallet

Цифровые платежи постоянно меняются. Мы хотим, чтобы они были быстрее, безопаснее и проще в использовании. В то же время совершенствуются инструменты цифровой идентификации, такие как верифицируемые учетные данные (Verifiable Credentials, VC) и мобильные документы, удостоверяющие личность (mdocs). Они предлагают новые способы подтверждения личности. Поэтому главный вопрос: смогут ли эти новые цифровые ID сделать цифровые платежи значительно лучше или проще?

В этой статье мы рассмотрим, как цифровые учетные данные (включая mdocs стандарта ISO и VC, передаваемые с помощью OpenID4VC) связаны с миром платежей. Мы затронем следующие темы:

• Как современные телефонные кошельки (Apple Wallet, Google Wallet) обрабатывают идентификационную информацию в сравнении с платежными картами.
• Почему текущие стандарты цифровых ID, такие как mdocs ISO 18013-5/7, на самом деле не подходят в качестве прямых платежных инструментов.
• Какую роль протоколы вроде OpenID4VC могут сыграть в будущих методах оплаты.
• Как другие (сторонние) приложения-кошельки могут реализовывать платежные функции.
• Основные проблемы и возможные сценарии будущего при попытке использовать верифицируемые учетные данные в платежных системах.

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

Чтобы понять, как цифровые учетные данные могут использоваться в платежах, нам сначала нужно разобраться, как основные мобильные платформы и их встроенные кошельки (Apple Wallet, Google Wallet) разделяют идентификационную информацию и процессы обработки платежей.

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

• Учетные данные для идентификации (например, mDL):
  • Apple Wallet: В основном поддерживает мобильные водительские удостоверения (mDL) и удостоверения личности штата, соответствующие стандарту ISO/IEC 18013-5. Начиная с WWDC25, Apple подтвердила, что Safari 26 (в iOS 26) будет поддерживать W3C Digital Credentials API для онлайн-предъявления, с эксклюзивным фокусом на протоколе org.iso.mdoc. Это предназначено для верификации атрибутов личности (например, имя, возраст, адрес), а не для платежей.
  • Google Wallet и Android Credential Manager: Google Wallet также поддерживает mDL на основе ISO 18013-5. Лежащий в основе Android Credential Manager предоставляет более гибкую структуру. Хотя его реализация Digital Credentials API не зависит от протокола, Android предоставляет реализацию по умолчанию, которая использует OpenID4VP в качестве транспортного механизма.
• Платежные инструменты (например, кредитные/дебетовые карты):
  • И Apple Pay (внутри Apple Wallet), и Google Pay (внутри Google Wallet) используют устоявшиеся, строго регулируемые платежные технологии. Они в основном базируются на стандартах EMV (Europay, Mastercard, Visa), включая токенизацию (Device PAN или DPAN, заменяющие реальные номера карт для транзакций), защищенные элементы или аппаратную безопасность для хранения платежных токенов, а также динамические криптограммы для безопасности транзакций.
  • Эти платежные системы напрямую взаимодействуют с существующими платежными сетями (Visa, Mastercard, Amex и т.д.) и банками-эквайерами.

Ключевой вывод: Нативные кошельки платформ в настоящее время работают с раздельными «стеками» или технологиями для учетных данных идентификации и платежных карт. mdoc предъявляется для подтверждения атрибута личности; токенизированная карта предъявляется для совершения платежа. Прямого использования mdoc в качестве платежного инструмента в этих нативных экосистемах нет.

Стандарт ISO/IEC 18013-5 определяет структуру данных для mDL и других мобильных ID (mdocs). Хотя он отлично подходит для верификации личности, его дизайн не приспособлен для прямого использования в качестве платежного инструмента:

Даже если бы в mdoc теоретически можно было добавить пользовательские поля данных для хранения PAN или платежного токена (поскольку ISO 18013-5 допускает пользовательские пространства имен), сам стандарт mdoc не определяет:

• Как генерировать или обрабатывать динамические платежные криптограммы.
• Как выполнять онлайн-авторизацию с платежной сетью.
• Необходимые механизмы безопасности, специфичные для платежных транзакций (помимо целостности данных о личности).

Таким образом, в настоящее время нет способа использовать mdoc стандарта ISO 18013-5 в качестве прямого платежного инструмента.

Хотя mdoc не является платежным инструментом, он может играть роль в процессе «повышенной аутентификации» (step-up authentication), когда личность пользователя должна быть явно проверена для действия с высоким риском. Это отличается от его использования для выполнения самого платежа. Процесс обычно выглядит так:

1. Первичная аутентификация: Пользователь входит в сервис, часто с помощью метода с низким уровнем трения, такого как passkey.
2. Триггер для повышения уровня аутентификации: Для действия с высоким уровнем безопасности (например, крупный банковский перевод, обновление личных данных) сервис требует явной проверки личности.
3. Предъявление mdoc: Сервис запрашивает предъявление mdoc пользователя (например, водительского удостоверения). Пользователь предъявляет необходимые атрибуты из своего кошелька.
4. Верификация: Сервис криптографически проверяет данные mdoc по доверенному источнику или ранее зарегистрированной личности.

В этой модели mdoc предоставляет сильное, устойчивое к фишингу доказательство личности для конкретного момента с высоким риском. Однако последующая финансовая транзакция все равно использует устоявшиеся платежные каналы. Mdoc верифицирует человека, а не метод оплаты.

Хотя сами mdocs не являются платежными инструментами, протоколы, такие как OpenID for Verifiable Credentials (OpenID4VC, включающий OpenID4VP для предъявления и OpenID4VCI для выпуска), предлагают более гибкий транспортный уровень.

Ключевые характеристики OpenID4VC:

• Протокол, а не содержимое: OID4VC определяет, как запрашивать и предъявлять VC, но в значительной степени не зависит от формата самого содержимого VC. Он может передавать mdocs, стандартные VC от W3C (например, в формате JWT или SD-JWT) или другие типы пользовательских учетных данных.
• Широта применения: Эта гибкость позволяет платформам, таким как Android (через его Credential Manager), поддерживать запросы на различные типы учетных данных через общий механизм.
• Будущая совместимость с платежными VC: Если бы платежная индустрия стандартизировала верифицируемый формат «платежного токена» или «авторизации платежа», OID4VC теоретически мог бы передавать такие учетные данные между кошельком пользователя и продавцом/PSP.

Однако сам OID4VC не является платежным решением:

• Роль OID4VC заключается в облегчении обмена учетными данными. Он не определяет содержание платежных учетных данных, их функции безопасности или то, как они взаимодействуют с системами обработки платежей.
• Чтобы OID4VC был полезен для платежей, сначала необходимо разработать и внедрить в платежной экосистеме (эмитенты, эквайеры, сети) широко распространенный, безопасный и стандартизированный формат верифицируемых платежных учетных данных. В настоящее время такого формата не существует.

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

Формируется консенсус, что Passkeys идеально подходят для основной аутентификации в платежном сервисе, поскольку они устойчивы к фишингу и разработаны для бесшовного пользовательского опыта. Включение предъявления цифровых учетных данных в критически важный шаг подтверждения платежа добавит значительное трение и, вероятно, навредит коэффициенту конверсии. Поэтому основная роль цифровых учетных данных заключается в однократном этапе онбординга и KYC с высоким уровнем гарантий, который открывает доступ к платежным возможностям, а не в самой транзакции. Как эти кошельки могут подходить к платежам, особенно в сочетании с функциями цифровой идентификации?

Чтобы сторонний кошелек мог авторизовать платеж, ему нужен способ вызова из приложения или с веб-сайта продавца. Существует несколько устоявшихся моделей взаимодействия для этого, каждая с разным уровнем интеграции с платформой и пользовательским опытом:

• Глубокие ссылки между приложениями (App-to-App Deep Linking): Это универсальный метод, при котором приложение продавца (нативное или веб) перенаправляет пользователя в приложение стороннего кошелька с помощью пользовательской схемы URL (например, eudi-wallet://...). Детали транзакции передаются в качестве параметров в URL. После того как пользователь подтверждает платеж в приложении кошелька, оно перенаправляет его обратно в приложение продавца с помощью другой глубокой ссылки. Это работает как на iOS, так и на Android, но включает видимое переключение контекста между приложениями.
• Нативный выбор кошелька (Native Wallet Selection): При нативном выборе кошелька приложение может вызвать общую системную службу, которая отображает все зарегистрированные обработчики платежей или кошельки. Затем пользователь может выбрать предпочитаемый кошелек из системного интерфейса. Это обеспечивает более интегрированное ощущение, чем простые глубокие ссылки (Digital Credential API).
• Простые платежи на основе QR-кода: Эта модель идеально подходит для сценариев «с компьютера на мобильный». Веб-сайт продавца отображает QR-код, содержащий детали транзакции или URL. Пользователь сканирует этот код своим мобильным приложением-кошельком, которое затем самостоятельно обрабатывает подтверждение на телефоне. Бэкенд кошелька затем сообщает об одобрении системе продавца.
• Стандартизированные межплатформенные потоки (FIDO CTAP): Эволюция метода с QR-кодом, использующая протоколы, такие как Client to Authenticator Protocol (CTAP) от FIDO, для создания прямого, безопасного и зашифрованного канала между браузером на компьютере (клиент) и мобильным кошельком (действующим как аутентификатор). Это более безопасно, чем простые QR-коды, поскольку браузер и телефон общаются напрямую — модель, активно поддерживаемая Google как для Passkeys, так и для цифровых учетных данных.
• Прямая интеграция с бэкендом: В некоторых замкнутых системах приложение стороннего кошелька может напрямую взаимодействовать с поставщиком платежных услуг (PSP) или бэкендом финансового учреждения для обработки платежей, часто используя проприетарные API.

Эти модели обеспечивают «транспортный уровень» для инициации подтверждения платежа, в рамках которого затем может происходить криптографический процесс (подобный тому, что описан для EUDI Wallet).

С анонсами на WWDC25 картина того, как браузеры обрабатывают цифровые учетные данные, стала намного яснее, укрепив разделение между верификацией личности и обработкой платежей. Платформы позволяют сторонним кошелькам взаимодействовать с браузерами для верификации личности через W3C Digital Credentials API, но подходы расходятся:

• Позиция Apple (подтверждено на WWDC25): Apple официально объявила о поддержке Digital Credentials API в Safari 26 (поставляется с iOS 26). Как подробно описано в их сессии «Verify identity documents on the web», реализация эксклюзивно поддерживает протокол org.iso.mdoc. Это позволяет веб-сайтам запрашивать верифицируемую информацию из mdocs в Apple Wallet или других зарегистрированных сторонних приложениях-поставщиках документов, но не поддерживает более универсальный протокол OpenID4VP. С ростом поддержки цифровых учетных данных и улучшенных веб-интеграций поддержание производительности и безопасности системы становится еще более важным — инструменты вроде CleanMyMac помогают обеспечить бесперебойную работу вашего Mac по мере развития этих технологий.
• Позиция Google: Credential Manager в Android позволяет сторонним кошелькам регистрироваться в качестве обработчиков запросов учетных данных. Его реализация Digital Credentials API в Chrome фокусируется на использовании OpenID4VP в качестве основного транспортного протокола. Хотя OpenID4VP может переносить mdoc в качестве полезной нагрузки, сам протокол отличается от прямого подхода Apple с org.iso.mdoc.

Важно отметить, что эти интеграции с браузером предназначены для атрибутов личности, а не для использования предъявленного mDoc или VC в качестве платежного инструмента.

Если пользователь предъявляет mDL из своего кошелька на веб-сайте через Digital Credentials API браузера, этот сайт может использовать информацию для предварительного заполнения адреса или проверки возраста при оформлении заказа. Однако сам этап оплаты все равно потребует отдельного взаимодействия с платежным методом (например, Apple Pay, Google Pay или ввод данных карты). Сам API браузера не предназначен для инициирования или обработки финансовой транзакции с использованием учетных данных личности.

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

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

Ключевые выводы из сравнения:

• Digital Credentials API: Этот развивающийся стандарт W3C не зависит от протокола и хорошо поддерживается для идентификации на обеих платформах. Для его реализации Android предоставляет стандартный поток с использованием гибкого протокола OpenID4VP, который может переносить различные форматы учетных данных. Реализация Apple, напротив, строго предназначена для формата org.iso.mdoc. Важно, что браузеры ограничивают этот API случаями использования для идентификации, а не для инициирования платежей.
• Нативный выбор кошелька: Обе операционные системы предоставляют нативный интерфейс для выбора кошелька, но с разными ограничениями. Android предлагает выбор как для приложений идентификации, так и для платежных приложений. iOS предоставляет выбор для зарегистрированных приложений «Поставщик документов» для идентификации, но не предлагает его для сторонних платежных приложений.
• Глубокие ссылки между приложениями: Это универсальный рабочий инструмент, надежно функционирующий как для идентификации, так и для платежей на обеих платформах. Он остается основным методом вызова стороннего кошелька для платежей на iOS.
• Стандартизированные межплатформенные потоки: Этот поток на основе FIDO CTAP в настоящее время является особенностью экосистемы Google/Android и не поддерживается на iOS.

(*) Примечание о платежах через DC API: Хотя использование OpenID4VP в Android делает платежный поток технически возможным через Digital Credentials API, это не является его основной целью. Бесшовная интеграция для платежей через этот конкретный API, в отличие от других нативных методов, еще предстоит увидеть и потребует явной поддержки со стороны поставщиков браузеров.

Это сравнение ясно показывает, что в то время как верификация личности все больше стандартизируется через Digital Credentials API, авторизация платежей для сторонних кошельков, таких как EUDI Wallet, по-прежнему в значительной степени зависит от более традиционных нативных моделей интеграции, таких как глубокие ссылки между приложениями, особенно на iOS.

Независимо от того, какая модель интеграции платежей используется для вызова кошелька, ядро подтверждения платежа в кошельке EUDI опирается на стандартизированный криптографический процесс, подробно описанный в EWC RFC008.

Ниже приведено общее описание этого процесса:

Это ненормативный пример объекта payment_data, который отправляется в кошелек и содержит детали транзакции для подтверждения пользователем.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

После одобрения пользователем кошелек создает JWT с привязкой ключа. Его поля доказывают, что пользователь подтвердил конкретные данные транзакции.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

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

Мощный способ понять потенциал верифицируемых учетных данных (VC) — сравнить их с успешными системами токенизации сетевых платежей (такими как Visa Token Service или Mastercard MDES).

• Токенизация платежей заменила чувствительный основной номер счета (PAN) на безопасный токен и одноразовую криптограмму. Это защищает основной актив — номер карты — во время транзакций.
• Верифицируемые учетные данные стремятся сделать для персональных данных то же, что токенизация сделала для PAN. Вместо того чтобы делиться необработанными данными (имя, дата рождения, адрес), пользователь предъявляет криптографически подписанные учетные данные от доверенного эмитента.

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

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

• EMVCo, орган по стандартизации безопасных платежей, активно интегрирует стандарты FIDO в протокол EMV 3-D Secure. Это позволяет использовать предыдущие аутентификации с помощью Passkeys как сильный сигнал для бесшовных одобрений, а также готовит почву для Secure Payment Confirmation (SPC), чтобы служить современной, устойчивой к фишингу альтернативой традиционным проверкам с помощью одноразовых паролей. Также ведутся дискуссии о том, как верифицируемые учетные данные могут быть включены в эти процессы в будущем.
• Visa анонсировала Visa Payment Passkey Service, который надежно связывает аутентификатор FIDO с платежными учетными данными. Этот сервис предназначен для подтверждения личности и авторизации платежей одним бесшовным шагом, не прерывая процесс оформления заказа.
• Mastercard следует параллельной стратегии со своим Mastercard Payment Passkey Service, который использует их Token Authentication Service (TAS) для замены паролей и одноразовых паролей на биометрическую аутентификацию на основе Passkeys, тесно интегрированную с их сервисами токенизации (MDES).

Это показывает четкую тенденцию: индустрия движется к будущему, в котором кошелек сможет предъявлять криптографически верифицируемое доказательство как личности, так и авторизации платежа в едином стандартизированном процессе.

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

Регламент ЕС eIDAS 2.0 не просто предоставляет гражданам цифровой ID; он явно предусматривает использование EUDI Wallet в качестве метода для выполнения SCA для онлайн-платежей. Это означает, что в будущем банки и поставщики платежных услуг в ЕС могут быть обязаны принимать EUDI Wallet как способ подтверждения онлайн-транзакций пользователями, предоставляя стандартизированную альтернативу проприетарным банковским приложениям или SMS-кодам.

Знаковое антимонопольное соглашение в ЕС уже заставило Apple открыть свой ранее закрытый NFC-интерфейс на iPhone. Начиная с iOS 17.4 (выпущена 5 марта 2024 года), Apple внедрила необходимые API и позволила пользователям выбирать приложение для бесконтактных платежей по умолчанию, уложившись в обязательный срок Европейской комиссии до 25 июля 2024 года. Это уже не перспектива будущего, а текущая реальность в Европейской экономической зоне (ЕЭЗ).

Это изменение означает, что сторонние приложения-кошельки теперь могут предлагать свои собственные решения для оплаты касанием на iOS, положив конец многолетней монополии Apple Pay. Ключевые возможности, теперь доступные разработчикам, включают:

• Выбор кошелька по умолчанию: Пользователи в ЕЭЗ могут установить подходящее стороннее приложение в качестве своего приложения для бесконтактных платежей по умолчанию, которое можно вызвать двойным нажатием боковой кнопки.
• Полная интеграция: Эти кошельки могут использовать нативные функции безопасности iPhone, включая Face ID и Touch ID, для авторизации платежей.
• Реальное внедрение: Несколько крупных игроков уже запустили свои решения, включая Vipps MobilePay в Норвегии и PayPal в Германии.

Последствия этого открытия значительны и уже проявляются:

• Усиление конкуренции: Банки и финтех-компании теперь могут напрямую конкурировать с Apple Pay на его собственной платформе, что, как ожидается, приведет к снижению комиссий для эмитентов и стимулированию инноваций.
• Более широкое использование учетных данных: Те же API могут использоваться не только для платежей, но и для корпоративных пропусков, проездных билетов и ключей от отелей, без необходимости находиться в Apple Wallet.
• Путь к стандартизированным учетным данным: Это создает важный прецедент. Та же регуляторная логика, которая открыла интерфейс NFC для платежных приложений, в конечном итоге может быть использована для обязательной поддержки стандартизированных, нейтральных «верифицируемых платежных учетных данных» (подобных тем, что пилотируются для EUDI Wallet), позволяя им функционировать наряду с проприетарными решениями.
• Глобальный прецедент: Хотя изменение в настоящее время ограничено ЕЭЗ, оно создает мощный глобальный прецедент. Регуляторы в других регионах, включая США, внимательно следят за ситуацией, и это может ускорить аналогичные открытия по всему миру.

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

Основой любой будущей стратегии кошелька является безопасное, широко распространенное нативное приложение. Непосредственный приоритет — максимизировать охват вашего приложения и укрепить его аутентификацию как для входа в систему, так и для платежей.

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

2. Используйте Passkeys для платежей, следуя модели PayPal: Внедряйте Passkeys немедленно, не только для входа, но и для авторизации платежей. Стремитесь к опыту, близкому по паритету к нативным решениям платформ, таким как Apple Pay. В регуляторных средах, требующих строгой аутентификации клиентов (SCA), примите прагматичный подход PayPal:

   • Используйте Passkeys в качестве основного фактора аутентификации.
   • Комбинируйте их с сигналами доверенных устройств (например, «запомненные устройства», управляемые через ваше приложение или защищенные cookie), чтобы соответствовать фактору «владение» SCA.
   • Эта комбинация позволяет вам обеспечить бесшовный опыт подтверждения платежа с низким уровнем трения, который является одновременно высокозащищенным и соответствующим требованиям, не дожидаясь универсальной поддержки VC.

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

3. Следите за ростом верифицируемых платежных учетных данных: Концепция VC, несущего платежный токен, мощна, но еще не стандартизирована. Ваша роль здесь — быть активным наблюдателем и участником.

   • Действие: Внимательно отслеживайте прогресс в органах по стандартизации, таких как EMVCo и W3C. Будьте готовы использовать стандартизированные верифицируемые платежные учетные данные, если и когда они предоставят явное преимущество перед существующими потоками на основе Passkeys.

4. Интегрируйте цифровые учетные данные для сценариев идентификации: По мере того как кошельки цифровой идентификации (например, EUDI Wallet) набирают популярность, интегрируйте Digital Credentials API для задач, связанных с идентификацией, а не для платежей.

   • Действие: Используйте предъявление VC для процессов с высоким уровнем гарантий, где они преуспевают:
     • Онбординг и KYC: Упростите создание нового аккаунта.
     • Повышенная аутентификация: Верифицируйте личность для действий с высоким риском.
     • Восстановление аккаунта: Предоставьте безопасный путь для пользователей, потерявших свои устройства.

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

5. Неустанно сравнивайте с опытом в один клик: Стандарт современного платежного опыта задают лидеры, такие как Apple Pay и его близкий последователь в вебе, PayPal. Любой новый процесс, который вы внедряете, должен конкурировать с их почти мгновенным подтверждением в один клик. Все текущие сигналы указывают на то, что для подавляющего большинства транзакций устойчивость Passkeys к фишингу обеспечивает достаточный уровень защиты и превосходный пользовательский опыт. Не добавляйте шаг предъявления VC в платежный процесс, если это создает какое-либо заметное трение.

6. Следите за сигналами устройства внутри WebAuthn: Эволюция Passkeys не статична. Хотя ранние попытки предоставления сигналов, специфичных для устройства, были прекращены, органы по стандартизации активно работают над интеграцией более сильных сигналов доверия с привязкой к устройству непосредственно в протокол WebAuthn. Это позволило бы RP идентифицировать доверенное устройство во время аутентификации с помощью Passkey, дополнительно усиливая сигнал для систем оценки рисков без необходимости отдельного, внеполосного предъявления VC. Внимательно следите за этой областью, так как это наиболее вероятный путь к повышению безопасности без ущерба для бесшовного опыта Passkeys.

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

Чтобы цифровые учетные данные стали неотъемлемой частью платежных процессов, а не просто поддерживали KYC или аутентифицировали пользователей в платежных аккаунтах, необходимо решить несколько серьезных проблем:

1. Стандартизация VC специально для платежей: Необходимо разработать специальный, безопасный и широко признанный формат верифицируемых учетных данных для платежей. Он должен был бы инкапсулировать платежные токены, данные, специфичные для транзакции, и, возможно, динамические элементы безопасности, что значительно превосходит рамки текущих mdocs, ориентированных на идентификацию, или общих VC.
2. Интеграция с платежными сетями: Любое платежное решение на основе VC должно бесшовно интегрироваться с существующими глобальными платежными сетями (Visa, Mastercard и т.д.) или предлагать жизнеспособные новые каналы. Это включает в себя сложные технические, безопасностные и бизнес-модельные согласования.
3. Соответствие нормативным требованиям: Платежи строго регулируются (например, PSD2/SCA в Европе, PCI DSS в мире). Платежная система на основе VC должна была бы соответствовать всем соответствующим финансовым нормам, включая те, что касаются безопасности, защиты потребителей и борьбы с мошенничеством.
4. Внедрение эмитентами и эквайерами: Банки, финансовые учреждения (как эмитенты платежных VC) и эквайеры продавцов должны были бы инвестировать в инфраструктуру для поддержки такой системы.
5. Модель безопасности: Была бы необходима надежная модель безопасности специально для платежных VC, охватывающая выпуск, хранение (в идеале в защищенных элементах с аппаратной поддержкой), предъявление и отзыв в финансовом контексте.
6. Пользовательский опыт: Хотя VC могут предложить пользователю контроль, платежный опыт должен оставаться быстрым, интуитивно понятным и надежным, чтобы получить широкое распространение.

Будущие возможности:

• VC как квитанции об авторизации платежа: VC могли бы представлять собой криптографически подписанную «авторизацию» на оплату с привязанного счета, предъявляемую через OpenID4VP, при этом фактический перевод средств по-прежнему происходил бы по традиционным каналам.
• VC, содержащие платежные токены: Можно было бы определить стандартизированный VC для безопасного хранения платежного токена (аналогично EMV DPAN), который затем обрабатывался бы существующими платежными инфраструктурами.
• Платежные VC в замкнутых системах: Конкретные эмитенты или сообщества могли бы создавать VC для платежей в своих собственных замкнутых системах.

Однако в настоящее время это в основном концептуальные идеи. Основной движущей силой текущей разработки VC и mdoc, теперь подкрепленной конкретными реализациями API браузеров, остается фокус на верификации личности и аттестации атрибутов, а не на выполнении платежей.

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

Стратегический план ясен. Немедленный шаг с низким риском — сосредоточиться на создании непревзойденного нативного приложения, используя его как средство для развертывания платежей на основе Passkeys, которые могут конкурировать с бесшовным стандартом «одного клика», установленным Apple Pay и PayPal. Этот подход удовлетворяет основные потребности в безопасности (через устойчивость к фишингу) и пользовательском опыте уже сегодня, используя зрелые, широко распространенные технологии.

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

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