Динамическое связывание с Passkeys: Secure Payment Confirmation (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

В нашей подробной серии из четырех частей ( часть 1, часть 2, часть 3 и часть 4) о PSD2 мы рассмотрели, как ключи доступа (passkeys) интегрируются с мерами строгой аутентификации клиента (SCA), введенными директивой PSD2. Мы уделили особое внимание элементам аутентификации, которые требуются SCA для доступа к банковским приложениям. Требования SCA применяются не только к доступу к приложениям, но и к инициированию и подписанию электронных платежных транзакций удаленно. Более того, эти требования предписывают использование механизма, известного как динамическое связывание. В этой статье мы объясним, что такое динамическое связывание, и рассмотрим, как ключи доступа можно эффективно использовать для реализации этого механизма как сегодня, так и в будущем.

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

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

Динамическое связывание имеет решающее значение в PSD2, поскольку оно напрямую решает проблемы безопасности, связанные с удаленными электронными транзакциями, которые особенно уязвимы для различных видов мошенничества, таких как атаки «человек посередине».

Обеспечивая безопасность транзакции таким образом, динамическое связывание значительно снижает вероятность несанкционированных операций.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Статья 5 RTS расширяет требования к коду аутентификации при динамическом связывании. Эти требования включают:

• Осведомленность плательщика: Плательщик должен быть проинформирован о сумме платежной транзакции и о получателе.

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

• Специфичность кода аутентификации: Генерируемые и принимаемые коды должны быть специфичны для суммы транзакции и личности получателя, подтвержденных плательщиком. Любое изменение суммы или получателя приводит к аннулированию кода аутентификации.

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

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Крупные компании доверяют Corbado защиту своих пользователей и создание более удобных входов в систему с помощью passkeys. Получите бесплатную консультацию по passkeys прямо сейчас.

Получить бесплатную консультацию

Давайте сначала проанализируем различные варианты использования ключей доступа в динамическом связывании.

В этом подходе сам ключ доступа выступает в качестве криптографического утверждения (assertion), которое используется непосредственно как код аутентификации. Запрос (challenge), выдаваемый в процессе транзакции, генерируется таким образом, чтобы конкретно отражать детали транзакции, такие как сумма и получатель, и хранится вместе с этой информацией. Когда пользователь авторизует транзакцию с помощью своего ключа доступа, генерируется уникальная, криптографически защищенная подпись, которую можно проверить и сохранить вместе с транзакцией. Этот ответ не только служит надежным фактором аутентификации, но и напрямую связывает подтверждение с конкретными деталями транзакции, строго соблюдая требования PSD2 к динамическому связыванию.

Become part of our Passkeys Community for updates & support.

Join

Более продвинутая интеграция включает кодирование дополнительных деталей транзакции в сам запрос WebAuthn (что технически не требуется PSD2/RTS). Этот метод предполагает включение криптографического хеша получателя и суммы, а также других случайных данных, в запрос. Таким образом, процесс аутентификации не только проверяет личность пользователя через ключ доступа, но и криптографически подтверждает целостность деталей транзакции. Этот подход предлагает дополнительный уровень безопасности, гарантируя, что любое вмешательство в сумму или данные получателя будет обнаружено на этапе окончательного платежа. Криптографическое доказательство становится неизменной частью кода аутентификации, повышая доверие и безопасность в средах с высоким риском транзакций (подробнее здесь).

Давайте проанализируем ограничения и проблемы этих двух вариантов.

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

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

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

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

Что такое контекст платежа от первого лица?

✔️ В контексте платежа от первого лица пользователь напрямую взаимодействует с эмитентом / банком на его интернет-сервисе и домене. Ключи доступа могут быть зарегистрированы и аутентифицированы без проблем. Примером может служить банк, который регистрирует ключ доступа на своем собственном веб-сайте и использует его для авторизации инициирования платежа из своего программного обеспечения для онлайн-банкинга. Здесь ключи доступа работают безупречно. Банк может гарантировать, что ключ доступа используется в пределах его домена, сохраняя контроль над платежной средой и безопасностью транзакции.

Пожалуйста, ознакомьтесь с нашей статьей о внедрении ключей доступа Mastercard в контексте платежа от первого лица.

Что такое контекст платежа от третьего лица?

В контексте платежа от третьего лица пользователь находится на странице мерчанта в процессе оформления заказа на другом домене (например, amazon.com) и хочет инициировать транзакцию по кредитной карте:

• ✔️ Случай 1 – У пользователя уже есть ключ доступа от его эмитента / банка: Мерчант показывает iframe, где может произойти аутентификация с помощью ключа доступа. IFRAME отображается в рамках существующего процесса 3-D Secure 2 (3DSS/EMV 3DS), который уже используется для транзакций по кредитным картам, требующих поддержки SCA и динамического связывания.

• ❌ Случай 2 – У пользователя нет ключа доступа от его эмитента / банка: Опять же, мерчант показывает iframe. Поскольку ключей доступа еще нет, пользователь аутентифицируется с помощью существующих факторов аутентификации (например, SMS OTP или нативного банковского приложения на смартфоне). В этот момент, после успешной аутентификации, было бы идеально зарегистрировать ключ доступа для пользователя, но это не разрешено из-за ограничений стандарта WebAuthn. Регистрация ключей доступа в cross-origin iframe не допускается (домен основной страницы и iframe должны быть идентичны). Постепенное внедрение, как на следующем скриншоте, было бы невозможным:

Будет ли в будущем поддерживаться регистрация passkeys в cross-origin iframes?

Хотя ключи доступа предлагают хорошее решение для динамического связывания в контексте платежей от первого лица в рамках одного домена, в контекстах платежей от третьих лиц они в настоящее время не поддерживаются WebAuthn Level 2. Однако хорошая новость заключается в том, что поддержка cross-origin iframe уже включена в разрабатываемую спецификацию WebAuthn Level 3 (которая станет общедоступной к концу 2024 года). Тем не менее, браузерам еще предстоит догнать спецификацию:

На сегодняшний день кажется, что к 2024 году поддержка регистрации passkeys в cross-origin может стать реальностью в основных браузерах, что снимет самое значительное техническое ограничение в использовании ключей доступа для платежей.

Рабочие группы W3C, инициированные Google, предприняли несколько попыток (например, BasicCard, PaymentHandler или PaymentManifest) улучшить опыт оплаты в вебе. До сих пор ни одна из них не получила значительного рыночного охвата и использования. Трудности в процессе оплаты для транзакций в электронной коммерции остаются большой проблемой на фоне ужесточения регулирования против мошенничества. Стандарт Secure Payment Confirmation, инициированный Google и Stripe, в настоящее время является самым многообещающим стандартом, основанным на стандарте WebAuthn.

Secure Payment Confirmation (SPC) затрагивает все важные элементы PSD2 SCA, включая требование динамического связывания, и в то же время пытается улучшить пользовательский опыт (UX).

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

Пример из https://www.w3.org/press-releases/2023/spc-cr/

• Предоставить криптографическое доказательство: Стандарт гарантирует, что криптографическое доказательство подтверждения пользователем деталей платежа генерируется и включается в утверждение (assertion) WebAuthn без необходимости кодировать информацию в запрос WebAuthn.

• Разрешить регистрацию от третьих лиц: В отличие от стандарта WebAuthn Level 2, где регистрация аутентификатора должна происходить в контексте первого лица, SPC позволяет регистрировать ключи доступа непосредственно из cross-origin iframe. Эта возможность решает распространенные сценарии использования в платежной экосистеме и облегчает интеграцию для мерчантов и платежных процессоров. Как мы обсуждали выше, эта функциональность уже является частью следующей версии базового стандарта и, следовательно, вероятно, будет удалена из SPC в будущем.

• Междоменная (Cross-Origin) аутентификация платежей: SPC расширяет возможности WebAuthn, позволяя любому источнику (origin) генерировать утверждение (assertion) для транзакции, даже если он использует учетные данные другой доверяющей стороны (Relying Party) (без необходимости покидать страницу). В этом случае даже iframe от мерчанта / эмитента не требуется. Эта функция особенно полезна в сценариях, где в процессе аутентификации участвуют несколько сторон (мерчант + эмитент / банк), и утверждение (assertion) затем может быть передано исходной доверяющей стороне (поставщику счета, например, банку) для проверки.

Приведенный выше пример взят из пояснения к SPC и показывает концепцию междоменной (Cross-Origin) аутентификации платежей: в процессе оплаты с использованием SPC пользователь остается на сайте мерчанта (выделено синим) на протяжении всей транзакции. Веб-браузер (окрашен в зеленый) продолжает отображать источник мерчанта, а также представляет предопределенный, не настраиваемый диалог со всей важной информацией для динамического связывания (сумма + получатель) для подтверждения транзакции. После подтверждения пользователем операционная система (изображена оранжевым) обрабатывает биометрическую аутентификацию, необходимую для проверки транзакции.

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

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

Как мы видим, наиболее важным отличием является регистрация на сайте мерчанта в iframe, которая еще не поддерживается стандартными ключами доступа (см. наше обсуждение выше), и совершенно новая возможность междоменной (Cross-Origin) аутентификации. Давайте рассмотрим их по очереди.

Вот макет примера регистрации SPC passkey непосредственно на странице Mastercard. Как вы можете видеть, создание ключа доступа предлагается сразу после завершения аутентификации через SMS OTP в данном случае.

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

Взято из https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

Этот SPC passkey теперь можно использовать на сайте мерчанта для аутентификации, в iframe на сайте мерчанта и для междоменной аутентификации (см. ниже).

Как мы уже обсуждали, процесс регистрации SPC passkey на сайте мерчанта обычно происходит во время платежной транзакции в контексте потока 3-D Secure (3DS). Этот поток предназначен для повышения безопасности онлайн-транзакций по кредитным и дебетовым картам путем введения дополнительного шага аутентификации, который проверяет личность держателя карты.

Во время платежной транзакции, когда инициируется поток 3DS, процесс аутентификации облегчается через iframe, размещенный на сайте мерчанта (например, amazon.com), но контролируемый поставщиком платежных услуг или банком-эмитентом (например, mastercard.com). Этот iframe служит безопасной средой для аутентификации клиента с использованием существующих факторов аутентификации.

Как только клиент успешно аутентифицируется с помощью этих традиционных факторов (например, SMS OTP или банковского приложения), появляется возможность зарегистрировать SPC passkey для будущих транзакций. Поскольку стандарт SPC разрешает создание cross-origin passkey из iframe, это будет работать. Регистрация этого ключа доступа в iframe обычно включает в себя выполнение клиентом действия, которое генерирует и привязывает ключ доступа к его кредитной карте, например, проверку отпечатка пальца или распознавание лица на совместимом устройстве. Имейте в виду, что iframe контролируется поставщиком платежных услуг (например, PayPal) или банком-эмитентом (например, mastercard.com). Следовательно, SPC passkey создается непосредственно у эмитента / банка, а не у мерчанта. Упрощенный поток будет выглядеть так:

Взято из https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

На https://spc-merchant.glitch.me/ Google создал демонстрационное приложение, доступное через Chrome на Windows и Mac, которое иллюстрирует, как это будет работать из iframe:

Оно также позволяет поэкспериментировать непосредственно с сайтом банка, который размещен по адресу: https://spc-rp.glitch.me/reauth. В этом примере не требуется внеполосная коммуникация с API между мерчантом и эмитентом / банком – все обрабатывается браузером. Аутентификация с использованием существующего ключа доступа будет работать таким же образом из iframe.

В следующем примере мы видим междоменную аутентификацию, где пользователь уже зарегистрировал SPC Passkey в Mastercard. Пример сайта мерчанта (decorshop.com) может запустить междоменную аутентификацию. Основное и важное отличие заключается в том, что страница мерчанта / эмитента никогда не видна во время процесса аутентификации. Браузер в сочетании с операционной системой представляет предопределенный платежный UX (предоставляемый реализацией стандарта SPC в браузере) и модальное окно аутентификации (стандарт WebAuthn). Коммуникация между мерчантом и эмитентом / банком обрабатывается в фоновом режиме.

Оригинал (частично изменен): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

Оригинал (частично изменен): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

При использовании междоменной аутентификации мерчант общается с эмитентом / банком через какой-либо API для обмена информацией о существующих учетных данных (№2 на диаграмме последовательности выше). Если учетные данные существуют и браузер пользователя поддерживает SPC, начинается аутентификация. В конце утверждение (assertion) возвращается обратно эмитенту / банку через существующие протоколы, такие как EMV 3DS, где утверждение может быть окончательно криптографически проверено (№16).

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

Стандарт Secure Payment Confirmation (SPC) — это интересная разработка в мире аутентификации онлайн-платежей, направленная на повышение безопасности при одновременном упрощении пользовательского опыта. На сегодняшний день Google Chrome является единственным крупным браузером, который в той или иной форме поддерживает SPC. Однако это не удивительно, поскольку стандарт был частично инициирован Google. Со стороны других крупных браузеров, таких как Apple Safari и Mozilla Firefox, наблюдается заметное отсутствие обязательств без четких сигналов о их планах по поддержке SPC. В частности, Apple продвигает свой собственный проприетарный стандарт Apple Pay и, похоже, не заинтересована в других платежных стандартах.

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

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

Проблемы, описанные выше, особенно связанные с осведомленностью плательщика, побудили к текущей работе в рабочей группе WebAuthn над так называемым расширением подтверждения (ранее известным как «txAuthSimple») в рамках стандарта WebAuthN. Его цель — позволить либо аутентификатору, либо браузеру/ОС (в привилегированном пользовательском интерфейсе) отображать детали транзакции пользователю и гарантировать, что доверяющая сторона получит криптографическое доказательство того, что пользователь действительно подтвердил эти детали. Это напрямую решает проблему «отсутствия гарантированной осведомленности пользователя», описанную в разделе 3.3.1.

Подобно тому, как Secure Payment Confirmation (SPC) предоставляет специальный, управляемый браузером диалог, расширение подтверждения решает проблему «Что видишь, то и подписываешь» (WYSIWYS). Его основные цели:

• Доверенное отображение деталей транзакции: Вместо того чтобы оставлять отображение суммы и получателя на усмотрение веб-контента, расширение использует либо защищенный экран устройства, либо диалоговое окно пользовательского интерфейса браузера под контролем ОС.
• Криптографическое доказательство: Аутентификатор (или клиентская платформа) подписывает запись точного отображенного текста. Проверяя эту подпись, доверяющая сторона может подтвердить, что пользователю были показаны правильные детали.
• Резервный вариант, если аутентификатор не поддерживает отображение: В случаях, когда аппаратный аутентификатор не может отображать текст, браузер может отобразить его и включить в [=client data=]. Это более слабая гарантия, но она обеспечивает более широкую совместимость.

Расширение добавляет новое поле в существующие структуры расширений WebAuthn. Доверяющие стороны предоставляют простую текстовую строку (с необязательным базовым форматированием), называемую confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

Когда клиент (браузер) получает это, он:

1. Запрашивает у пользователя специальный диалог подтверждения (чтобы он знал, что это больше, чем просто вход в систему).
2. Передает ту же строку аутентификатору в виде данных CBOR, если аутентификатор поддерживает расширение.
3. Возвращает любой вывод аутентификатора доверяющей стороне.

Если аутентификатор поддерживает отображение текста, он должен показать этот текст (например, на своем собственном экране или в доверенном пользовательском интерфейсе) перед завершением проверки пользователя. Затем он включает ту же строку в свой подписанный вывод.

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

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

• Любое несоответствие или изменение деталей транзакции после отображения делает подпись недействительной.
• Доверяющая сторона может доказать, что пользователю были предоставлены правильные детали транзакции во время подписания, выполняя требование PSD2 об «осведомленности плательщика» гораздо надежнее, чем простое хеширование данных в запросе.

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

• Интероперабельность: Любой аутентификатор или клиент, реализующий расширение, будет следовать одному и тому же стандартизированному формату.
• Гибкость: Доверяющие стороны могут применять более строгие политики (требуя отображения на уровне аутентификатора) или принимать резервный вариант на уровне браузера, если это необходимо.
• Более широкое соответствие экосистеме: Оно хорошо согласуется с регуляторными мандатами, такими как PSD2, особенно в отношении надежного динамического связывания.

Для получения более подробной технической информации вы можете ознакомиться с текущим обсуждением: GitHub pull request #2020. В итоге, расширение подтверждения также могло бы закрыть последний крупный пробел в стандартных потоках на основе ключей доступа: предоставление криптографического доказательства того, что именно пользователь видел, когда давал свое согласие, хотя и менее структурированно, чем с Secure Payment Confirmation. Если оно получит поддержку среди браузеров и производителей аутентификаторов, оно может стать высокостандартизированным методом для обеспечения гарантии безопасности WYSIWYS, необходимой в рамках динамического связывания PSD2 и не только.

Хотя SPC и расширение подтверждения имеют общую цель — усилить динамическое связывание в WebAuthn, они различаются по объему и подходу. В таблице ниже выделены некоторые из этих различий:

По сути, SPC пытается предложить комплексное платежное решение* и также включает динамическое связывание* как часть своего потока. Расширение подтверждения*, в свою очередь, решает требование «что видишь, то и подписываешь» внутри стандартных сообщений WebAuthn, не навязывая полного платежного потока. Любой из подходов может способствовать соблюдению PSD2, но каждый зависит от поддержки браузеров и аутентификаторов для предоставления реальных преимуществ.

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

• ✔️ Passkeys для платежей, инициированных на сайте эмитента / банка: Passkeys — очень хорошее решение для эмитентов / банков для внедрения динамического связывания непосредственно на их веб-сайты и в приложения. Их можно комбинировать с другими вариантами аутентификации, такими как push-уведомления, OTP по электронной почте / SMS или TOTP, для дальнейшего повышения безопасности платежей с высоким риском. Конечно, соображения относительно соответствия SCA всегда должны быть частью этого обсуждения (см. также нашу серию из 4 частей о passkeys и SCA).

  Предлагаемое решение может быть реализовано самими эмитентами / банками, поскольку passkeys основаны на открытом стандарте WebAuthn. Однако это требует значительных ноу-хау, решения крайних случаев и постоянного отслеживания всех новых нормативных актов и технических разработок. Альтернативой является использование стороннего поставщика аутентификации. Например, Corbado Connect поддерживает динамическое связывание через подписание транзакций, используя скорректированные запросы WebAuthn. Вся информация регистрируется в журнале аудита. Это полезно не только для финансовых учреждений, но и может быть использовано для всех видов подписей (например, подписание документов, действия пользователя с высоким риском). При желании можно использовать дополнительный OTP по SMS или электронной почте для еще большего повышения безопасности.

• ❌ Passkeys для платежей на страницах мерчантов: Внедрение passkeys для платежей на страницах мерчантов пока невозможно. Сценарии использования cross-origin все еще находятся в разработке, но могут стать жизнеспособным вариантом к концу 2024 года. Однако использование passkeys для аутентификации на страницах мерчантов уже сегодня является отличной идеей и может быть использовано для начала сбора passkeys, которые затем можно будет использовать и для платежей в будущем.

• ❌ SPC Passkeys или расширение подтверждения для динамического связывания: Стандарт SPC еще не достиг зрелого состояния и поддержки для использования в производственных средах.

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

Почему важны Passkeys?

Passkeys для предприятий

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

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

Рассматривая passkeys для динамического связывания, очевидно, что, хотя они могут помочь соблюдать требования SCA и динамического связывания, техническая интеграция в сторонние сервисы со стандартом WebAuthn, изначально разработанным для контекстов первого лица, представляет некоторые проблемы. Эти стандарты постепенно развиваются, чтобы лучше поддерживать сценарии с участием третьих сторон, демонстрируя сдвиг в сторону большей гибкости в их применении. Secure Payment Confirmation (SPC) стремится развить эту адаптацию, нацеливаясь на улучшение процессов аутентификации платежей путем включения более удобных и бесшовных взаимодействий на различных сайтах мерчантов.

Однако продвижение и более широкое признание стандарта SPC или расширения подтверждения в значительной степени зависят от его принятия основными браузерами — процесс, который идет медленно, и в настоящее время единственным сторонником является Google Chrome. Эта медленная скорость принятия может потенциально помешать, особенно SPC, выйти за рамки своего текущего состояния, если больше браузеров не начнут его интегрировать. Продолжающееся развитие и растущая популярность passkeys указывают на многообещающее направление, где системы, основанные на аппаратных модулях безопасности (HSM), таких как Secure Enclave, TEE и TPM, также будут играть важную роль в платежных приложениях, поскольку эти технологии предлагают повышенную безопасность, которая может сделать динамическое связывание платежей более практичным и удобным не только для транзакций, инициированных на банковских сайтах, но и на сторонних платформах мерчантов.

Потенциал passkeys для расширения их полезности на процессы онлайн-платежей подчеркивает важный аспект в обеспечении безопасности веб-транзакций и делает Интернет в целом более безопасным местом.