패스키를 이용한 동적 링킹: 보안 결제 확인(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

총 4부로 구성된 PSD2 시리즈(1부, 2부, 3부, 4부)에서는 PSD2가 도입한 강력한 고객 인증(SCA) 조치에 패스키가 어떻게 통합되는지 살펴보았습니다. 특히 은행 애플리케이션 접근 시 SCA가 요구하는 인증 요소에 초점을 맞췄습니다. SCA 요구사항은 애플리케이션 접근뿐만 아니라 원격으로 전자 결제 거래를 시작하고 서명하는 데에도 적용됩니다. 더 나아가, 이러한 요구사항은 **동적 링킹(dynamic linking)**이라는 메커니즘의 사용을 필요로 합니다. 이 글에서는 동적 링킹을 설명하고, 현재와 미래에 이 메커니즘을 효과적으로 구현하기 위해 패스키를 어떻게 활용할 수 있는지 살펴보겠습니다.

동적 링킹은 PSD2 지침과 그 이행 부록인 규제 기술 표준(RTS)에 따른 보안 요구사항입니다. 이 개념은 각 거래가 인증 코드를 통해 특정 금액 및 특정 수취인과 고유하게 연결되도록 보장하여 전자 결제의 보안을 강화하기 위해 도입되었습니다. 이러한 연결은 지급인이 거래를 인증한 후에는 거래 세부 정보가 수정되는 것을 방지하여 사기 위험을 줄입니다. 전자 결제에는 온라인 뱅킹 소프트웨어의 계좌 이체뿐만 아니라 판매자 사이트에서의 신용카드 결제도 포함됩니다.

PSD2 지침과 함께 제공되는 RTS에 따르면, 동적 링킹은 "생성된 인증 코드가 지급인이 전자 결제 거래를 시작할 때 동의한 금액과 수취인에 특정되도록" 보장하는 프로세스로 정의됩니다(PSD2 제97조 2항). 이는 결제 세부 정보에 변경이 있을 경우 인증 코드가 무효화되어 재인증이 필요하다는 것을 의미합니다.

동적 링킹은 특히 중간자 공격과 같은 다양한 유형의 사기에 취약한 원격 전자 거래와 관련된 보안 위험을 직접적으로 해결하기 때문에 PSD2에서 매우 중요합니다.

이러한 방식으로 거래를 보호함으로써 동적 링킹은 무단 거래의 가능성을 크게 낮춥니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

RTS 제5조는 동적 링킹의 인증 코드에 대한 요구사항을 다음과 같이 상세히 설명합니다.

• 지급인 인지: 지급인은 결제 거래 금액과 수취인을 인지해야 합니다.

• 인증 코드의 고유성: 각 거래에 대해 생성된 인증 코드는 고유해야 하며 다른 거래에 재사용할 수 없어야 합니다.

• 인증 코드의 특정성: 생성되고 수락되는 코드는 지급인이 확인한 거래 금액과 수취인의 신원에 특정되어야 합니다. 금액이나 수취인이 변경되면 인증 코드는 무효화됩니다.

• 안전한 전송: 인증 코드의 생성, 전송 및 사용을 포함한 인증의 모든 단계에서 거래 금액과 수취인에 대한 기밀성, 인증성 및 무결성이 유지되어야 합니다.

동적 링킹의 이러한 기술적 요구사항을 바탕으로, 다음 섹션에서는 새로운 기술인 패스키가 어떻게 도움이 될 수 있는지 살펴보겠습니다. 결제 인증 프로세스를 간소화하고 보호하여 동적 링킹을 더욱 강력하고 사용자 친화적으로 만들 수 있는 패스키의 잠재력을 탐구해 보겠습니다.

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를 신뢰하여 사용자를 보호하고 패스키로 더욱 원활한 로그인을 구현합니다. 지금 무료 패스키 컨설팅을 받아보세요.

무료 상담 받기

먼저 동적 링킹에서 패스키를 사용할 수 있는 다양한 옵션을 분석해 보겠습니다.

이 접근 방식에서는 패스키 자체가 직접 인증 코드로 사용되는 암호화된 어설션 역할을 합니다. 거래 과정에서 발행되는 챌린지는 금액 및 수취인과 같은 특정 거래 세부 정보를 구체적으로 반영하도록 생성되며 해당 정보와 함께 저장됩니다. 사용자가 패스키를 사용하여 거래를 승인하면, 고유하고 암호학적으로 안전한 서명이 생성되어 거래와 함께 검증되고 저장될 수 있습니다. 이 응답은 강력한 인증 요소로 작용할 뿐만 아니라 승인을 특정 거래 세부 정보에 직접 연결하여 동적 링킹에 대한 PSD2의 요구사항을 엄격하게 준수합니다.

Become part of our Passkeys Community for updates & support.

Join

더 발전된 통합 방식은 추가적인 거래 세부 정보를 WebAuthn 챌린지 자체에 인코딩하는 것입니다(기술적으로 PSD2/RTS에서 요구하는 사항은 아닙니다). 이 방법은 수취인과 금액의 암호화 해시를 다른 임의의 데이터와 함께 챌린지에 포함시키는 것을 제안합니다. 이렇게 함으로써 인증 프로세스는 패스키를 통해 사용자의 신원을 확인할 뿐만 아니라 거래 세부 정보의 무결성을 암호학적으로 증명합니다. 이 접근 방식은 금액이나 수취인 세부 정보에 대한 어떠한 조작도 최종 결제 시점에서 감지할 수 있도록 보장하여 추가적인 보안 계층을 제공합니다. 암호화 증명은 인증 코드의 불변적인 부분이 되어 고위험 거래 환경에서 신뢰와 보안을 강화합니다(자세한 정보는 여기 참조).

이 두 가지 옵션의 한계와 과제를 분석해 보겠습니다.

동적 링킹, 특히 결제 인증의 맥락에서 패스키를 사용하는 것의 한계 중 하나는 지급인이 수취인 정보에 대해 정확하게 안내받았다는 구체적인 문서나 보장이 없다는 점입니다.

패스키는 안전한 사용자 인증 방법을 제공하지만, 모든 거래 세부 정보, 특히 수취인에 관한 정보가 지급인에게 올바르게 표시되었는지 여부를 본질적으로 검증하지는 않습니다.

이 문제는 패스키에만 국한된 것이 아니라 다양한 온라인 결제 시스템에서 공통적으로 나타나는 과제입니다. 지급인이 결제를 시작하기 전에 모든 거래 세부 정보를 완전히 인지하고 동의하도록 보장하는 것은 신뢰와 보안을 유지하는 데 매우 중요합니다.

패스키를 동적 링킹에 통합하는 데 있어 가장 큰 한계는 자사 등록과 제3자 등록의 구분에서 발생합니다.

자사 결제 컨텍스트란 무엇인가요?

✔️ 자사 결제 컨텍스트에서는 사용자가 자신의 인터넷 서비스 및 도메인에서 발급사/은행과 직접 상호작용합니다. 패스키는 원활하게 등록하고 인증할 수 있습니다. 예를 들어, 은행이 자체 웹사이트에서 패스키를 등록하고 이를 사용하여 온라인 뱅킹 소프트웨어에서 결제 개시를 승인하는 경우가 있습니다. 여기서는 패스키가 원활하게 작동합니다. 은행은 패스키가 자사 도메인 내에서 사용되도록 보장하여 결제 환경과 거래 보안에 대한 통제권을 유지할 수 있습니다.

자사 결제 컨텍스트에서의 Mastercard 패스키 구현에 대한 저희 블로그 게시물을 참조하세요.

제3자 결제 컨텍스트란 무엇인가요?

제3자 결제 컨텍스트에서는 사용자가 다른 도메인(예: amazon.com)의 판매자 페이지에서 결제 프로세스를 진행하며 신용카드 거래를 시작하려고 합니다.

• ✔️ 사례 1 – 사용자가 이미 발급사/은행의 패스키를 가지고 있는 경우: 판매자는 패스키 인증이 가능한 iframe을 표시합니다. 이 IFRAME은 SCA 및 동적 링킹을 지원해야 하는 신용카드 거래에 이미 적용되고 있는 기본 3-D Secure 2(3DSS/EMV 3DS) 프로세스에 의해 표시됩니다.

• ❌ 사례 2 – 사용자가 발급사/은행의 패스키를 가지고 있지 않은 경우: 이 경우에도 판매자는 iframe을 표시합니다. 아직 사용 가능한 패스키가 없으므로 사용자는 기존 인증 수단(예: SMS OTP 또는 스마트폰의 네이티브 뱅킹 앱)으로 인증됩니다. 이 시점에서 성공적인 인증 후 사용자에게 패스키를 등록해 주는 것이 이상적인 순간이지만, WebAuthn 표준 제한으로 인해 이는 허용되지 않습니다. 교차 출처 iframe에서의 패스키 등록은 허용되지 않습니다(메인 페이지와 iframe의 도메인이 동일해야 함). 다음 스크린샷과 같은 점진적인 등록은 불가능합니다.

교차 출처 iframe에서의 패스키 등록이 미래에 지원될까요?

패스키는 단일 도메인 내의 자사 결제 컨텍스트에서 동적 링킹을 위한 좋은 해결책을 제공하지만, 제3자 결제 컨텍스트에서는 현재 WebAuthn Level 2에서 지원되지 않습니다. 하지만 좋은 소식은 교차 출처 iframe 지원이 이미 진행 중인 WebAuthn Level 3 사양(2024년 말에 정식 공개될 예정)에 포함되어 있다는 것입니다. 그러나 브라우저들은 아직 이 사양을 따라잡아야 합니다.

현재로서는 2024년까지 주요 브라우저에서 패스키의 교차 출처 등록 지원이 현실화될 것으로 보이며, 이는 결제에 패스키를 사용하는 데 있어 가장 큰 기술적 한계를 해소할 것입니다.

웹에서의 결제 경험을 개선하기 위해 W3C의 Google 주도 워킹 그룹에서 여러 시도(예: BasicCard, PaymentHandler, PaymentManifest)가 있었습니다. 지금까지 어떤 것도 상당한 시장 점유율과 사용률을 얻지 못했습니다. 사기 방지를 위한 규제가 증가함에 따라 이커머스 거래의 결제 과정에서의 마찰은 여전히 큰 과제로 남아 있습니다. Google과 Stripe가 시작한 보안 결제 확인(Secure Payment Conformation) 표준은 현재 WebAuthn 표준을 기반으로 구축된 가장 유망한 표준입니다.

보안 결제 확인(SPC)은 동적 링킹 요구사항을 포함한 PSD2 SCA의 모든 중요한 요소를 다루면서 동시에 UX 경험을 개선하려고 시도합니다.

• 브라우저 네이티브 UX 제공: SPC는 브라우저를 활용하여 여러 판매자 사이트와 신뢰 당사자(relying parties)에 걸쳐 일관되고 간소화된 인증 경험을 제공합니다. 이 접근 방식은 일관된 외관을 가지고 지급인 인지를 보장함으로써 일반적으로 iframe에서 렌더링되는 콘텐츠로 달성되는 것 이상의 거래 보안을 강화하기 위한 것입니다.

https://www.w3.org/press-releases/2023/spc-cr/의 예시

• 암호화 증거 제공: 이 표준은 사용자의 결제 세부 정보 확인에 대한 암호화 증명이 생성되어 WebAuthn 어설션에 포함되도록 보장하며, 정보를 WebAuthn 챌린지에 인코딩할 필요가 없습니다.

• 제3자 등록 허용: 인증자 등록이 자사 컨텍스트에서 이루어져야 하는 WebAuthn Level 2 표준과 달리, SPC는 교차 출처 iframe에서 직접 패스키를 등록할 수 있게 합니다. 이 기능은 결제 생태계의 일반적인 사용 사례를 해결하고 판매자 및 결제 처리업체의 통합을 용이하게 합니다. 위에서 논의한 바와 같이 이 기능은 이미 차기 버전의 기본 표준에 포함되어 있으므로 향후 SPC에서 제거될 가능성이 높습니다.

• 결제의 교차 출처 인증: SPC는 다른 신뢰 당사자의 자격 증명을 활용하더라도 모든 출처가 거래에 대한 어설션을 생성할 수 있도록 하여 WebAuthn의 유용성을 확장합니다(페이지를 떠날 필요 없이). 이 경우 판매자/발급사의 iframe조차 필요하지 않습니다. 이 기능은 여러 당사자(판매자 + 발급사/은행)가 인증 프로세스에 관여하고 어설션이 검증을 위해 원래의 신뢰 당사자(계정 제공자, 예: 은행)에게 전송될 수 있는 시나리오에서 특히 유용합니다.

위 예시는 SPC 설명자(Explainer)에서 가져온 것으로, 결제의 교차 출처 인증 개념을 보여줍니다. SPC를 사용한 결제 프로세스에서 사용자는 거래 내내 판매자 사이트(파란색으로 강조 표시)에 머무릅니다. 웹 브라우저(녹색으로 표시)는 판매자의 출처 표시를 유지하며, 동적 링킹에 중요한 모든 정보(금액 + 수취인)가 포함된 사전 정의된 비-사용자 정의 대화 상자를 표시하여 거래를 확인합니다. 사용자가 확인한 후, 운영 체제(주황색으로 표시)는 거래를 확인하는 데 필요한 생체 인증을 처리합니다.

이러한 목표들은 온라인 결제의 보안과 사용자 경험을 모두 개선하려는 SPC의 노력을 보여주며, 디지털 결제 환경 전반에 걸쳐 높은 보안 표준을 유지하면서 인증 프로세스를 단순화하는 것을 목표로 합니다.

SPC가 허용하는 모든 가능한 흐름을 살펴보고 표준 패스키와 비교하여 그 이점을 이해해 보겠습니다.

여기서 볼 수 있듯이, 가장 중요한 차이점은 아직 패스키에서 지원되지 않는(위의 논의 참조) 판매자 웹사이트의 iframe 내 등록과 교차 출처 인증이라는 완전히 새로운 가능성입니다. 하나씩 살펴보겠습니다.

다음은 Mastercard 페이지에서 직접 SPC 패스키를 등록하는 모의 예시입니다. 보시다시피, 이 경우 SMS OTP를 통한 인증이 완료된 직후에 패스키 생성이 제공됩니다.

이 경우, 통신은 완전히 자사 컨텍스트에서 발생하므로 표준 패스키 등록 프로세스와 유사하게 보일 것입니다.

https://developer.chrome.com/docs/payments/register-secure-payment-confirmation에서 가져옴

이제 이 SPC 패스키는 판매자 사이트에서 인증, 판매자 사이트의 iframe 내, 그리고 교차 출처 인증(아래 참조)에 사용될 수 있습니다.

앞서 논의한 바와 같이, 판매자 웹사이트에서 SPC 패스키를 등록하는 과정은 일반적으로 3-D Secure(3DS) 흐름의 컨텍스트 내에서 결제 거래 중에 발생합니다. 이 흐름은 카드 소지자의 신원을 확인하는 추가 인증 단계를 포함하여 온라인 신용 및 직불 카드 거래의 보안을 강화하도록 설계되었습니다.

결제 거래 중 3DS 흐름이 시작되면, 인증 프로세스는 판매자 사이트(예: amazon.com)에 호스팅되지만 결제 서비스 제공업체 또는 발급 은행(예: mastercard.com)이 제어하는 iframe을 통해 진행됩니다. 이 iframe은 고객이 기존 인증 요소를 사용하여 신원을 인증할 수 있는 안전한 환경 역할을 합니다.

고객이 이러한 기존 요소(예: SMS OTP 또는 뱅킹 앱)를 사용하여 성공적으로 자신을 인증하면, 향후 거래를 위해 SPC 패스키를 등록할 기회가 생깁니다. SPC 표준은 iframe 내에서 교차 출처 패스키 생성을 허용하므로 이것이 가능합니다. 이 iframe에서 패스키를 등록하는 것은 일반적으로 고객이 호환되는 장치에서 지문이나 얼굴 인식을 확인하는 것과 같이 패스키를 생성하고 신용카드에 바인딩하는 작업을 수행하는 것을 포함합니다. iframe은 결제 서비스 제공업체(예: PayPal) 또는 발급 은행(예: mastercard.com)에 의해 제어된다는 점을 명심하세요. 따라서 SPC 패스키는 판매자가 아닌 발급사/은행과 직접 생성됩니다. 단순화된 흐름은 다음과 같습니다.

https://developer.chrome.com/docs/payments/register-secure-payment-confirmation에서 가져옴

Google은 https://spc-merchant.glitch.me/에 Windows 및 Mac의 Chrome을 통해 접속할 수 있는 데모 애플리케이션을 설정하여 iframe 내에서 이것이 어떻게 작동하는지 보여줍니다.

또한 https://spc-rp.glitch.me/reauth에서 호스팅되는 은행 사이트를 직접 사용해 볼 수도 있습니다. 이 예에서는 판매자와 발급사/은행 간의 API를 통한 대역 외 통신이 필요 없으며, 모든 것이 브라우저에 의해 처리됩니다. 기존 패스키를 사용한 인증도 iframe 내에서 동일한 방식으로 작동합니다.

다음 예에서는 사용자가 이미 Mastercard에 SPC 패스키를 등록한 교차 출처 인증을 볼 수 있습니다. 예시 판매자 사이트(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를 지원하면 인증이 시작됩니다. 마지막에 어설션은 EMV 3DS와 같은 기존 프로토콜을 통해 발급사/은행으로 다시 전달되며, 여기서 어설션은 최종적으로 암호학적으로 검증될 수 있습니다(#16).

어설션에는 브라우저에 표시된 정보에 대한 정보도 포함되므로 동적 링킹에 대한 모든 요구사항이 충족됩니다. 이는 UX 및 고객 결제 경험 개선 측면에서 큰 진전이 될 것입니다.

보안 결제 확인(SPC) 표준은 보안을 강화하면서 사용자 경험을 간소화하는 것을 목표로 하는 온라인 결제 인증 세계에서 흥미로운 발전입니다. 현재까지 Google Chrome이 어떤 형태로든 SPC를 지원하는 유일한 주요 브라우저입니다. 그러나 이 표준이 부분적으로 Google에 의해 시작되었기 때문에 이는 놀라운 일이 아닙니다. Apple의 Safari나 Mozilla Firefox와 같은 다른 주요 브라우저에서는 SPC 지원 계획에 대한 명확한 신호가 없어 헌신이 부족한 상황입니다. 특히 Apple은 자체 독점 표준인 Apple Pay를 추진하고 있으며 다른 결제 표준에는 관심이 없는 것으로 보입니다.

SPC와 WebAuthn의 연결은 개발 과정을 더 어렵게 만들었습니다. 이는 SPC 표준의 모든 개선이나 수정이 중복을 방지하고 기존 기능에 대한 진정한 개선을 제공하는지 신중하게 평가해야 하기 때문입니다. 목표는 결제 흐름에 직접 통합하고 여러 판매자 사이트에서 원활하게 작동할 수 있는 더 사용자 친화적인 인증 경험을 제공하는 등 WebAuthn이 완전히 다루지 못하는 결제 프로세스 내의 특정 요구를 충족하도록 SPC를 개선하는 것입니다.

SPC가 계속 발전함에 따라 여러 브라우저에서의 채택이 광범위한 구현에 중요할 것입니다. Google과 같은 주요 업체의 참여는 긍정적인 방향을 나타내지만, SPC가 온라인 결제 산업 전반의 표준으로 자리 잡기 위해서는 더 넓은 지원이 필요할 것입니다.

위에서 설명한 과제들, 특히 지급인 인지와 관련된 문제들은 WebAuthn 워킹 그룹에서 WebAuthN 표준 내에서 소위 확인 확장(이전 명칭 "txAuthSimple")에 대한 지속적인 작업을 촉발했습니다. 이 확장의 목표는 인증자 또는 브라우저/OS(권한 있는 UI에서)가 사용자에게 거래 세부 정보를 표시하고, 신뢰 당사자가 사용자가 실제로 이러한 세부 정보를 확인했다는 암호화 증명을 받을 수 있도록 하는 것입니다. 이는 섹션 3.3.1에서 설명한 "보장된 사용자 인지 부족" 문제를 직접적으로 해결합니다.

보안 결제 확인(SPC)이 전용 브라우저 기반 대화 상자를 제공하는 것과 유사하게, 확인 확장은 "WYSIWYS(What You See Is What You Sign)" 문제를 해결합니다. 주요 목표는 다음과 같습니다.

• 신뢰할 수 있는 거래 세부 정보 표시: 웹 콘텐츠에 금액과 수취인을 표시하도록 맡기는 대신, 이 확장은 장치의 보안 화면이나 OS의 통제 하에 있는 브라우저 UI 대화 상자를 활용합니다.
• 암호화 증거: 인증자(또는 클라이언트 플랫폼)는 표시된 정확한 텍스트의 기록에 서명합니다. 이 서명을 확인함으로써 신뢰 당사자는 사용자에게 올바른 세부 정보가 표시되었음을 확인할 수 있습니다.
• 인증자가 디스플레이를 지원하지 않는 경우의 대체 방안: 하드웨어 인증자가 텍스트를 표시할 수 없는 경우, 브라우저가 이를 표시하고 [=client data=]에 포함시킬 수 있습니다. 이는 보증 수준은 낮지만 더 넓은 호환성을 허용합니다.

이 확장은 기존 WebAuthn 확장 구조에 새로운 필드를 추가합니다. 신뢰 당사자는 confirmation이라는 간단한 텍스트 문자열(선택적으로 기본 서식 포함)을 제공합니다.

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

클라이언트(브라우저)가 이를 받으면 다음을 수행합니다.

1. 사용자에게 특별한 확인 대화 상자를 통해 프롬프트를 표시합니다(이것이 기본 로그인 이상임을 알 수 있도록).
2. 인증자가 확장을 지원하는 경우 동일한 문자열을 CBOR 데이터로 인증자에게 전달합니다.
3. 인증자 출력을 신뢰 당사자에게 반환합니다.

인증자가 텍스트 표시를 지원하는 경우, 사용자 확인을 완료하기 전에 해당 텍스트를 (예: 자체 화면이나 신뢰할 수 있는 UI에) 반드시 표시해야 합니다. 그런 다음 서명된 출력에 동일한 문자열을 포함합니다.

신뢰 당사자 측에서는 검증 단계를 통해 반환된 confirmation 텍스트가 전송된 것과 일치하는지 확인합니다. 인증자 확장 출력이 없지만 신뢰 당사자 정책이 대체 방안을 허용하는 경우, 신뢰 당사자는 클라이언트 데이터의 confirmation 값에 의존할 수 있으며, 이는 인증자 대신 브라우저가 텍스트를 표시했음을 나타냅니다.

수취인과 금액을 이 확장에 포함시킴으로써, 사용자는 신뢰할 수 있는 디스플레이에서 자신이 승인하는 내용을 정확하게 볼 수 있습니다. 이제 사용자의 서명은 해시된 챌린지뿐만 아니라 정확한 거래 텍스트도 반영합니다. 이는 PSD2의 동적 링킹 요구사항에 특히 유용합니다. 왜냐하면:

• 표시 후 거래 세부 정보의 불일치나 수정은 서명을 무효화합니다.
• 신뢰 당사자는 서명 시점에 사용자에게 올바른 거래 세부 정보가 제공되었음을 증명할 수 있어, 챌린지에 데이터를 해싱하는 것보다 훨씬 더 강력하게 PSD2의 "지급인 인지" 요구사항을 충족합니다.

확인 확장은 아직 논의 중이지만, 더 안전하고 사용자 친화적인 거래 흐름을 향한 중요한 단계를 나타냅니다. 이를 WebAuthn 사양에 직접 구축함으로써 다음과 같은 이점을 제공합니다.

• 상호 운용성: 확장을 구현하는 모든 인증자나 클라이언트는 동일한 표준화된 형식을 따릅니다.
• 유연성: 신뢰 당사자는 더 강력한 정책(인증자 수준 디스플레이 요구)을 시행하거나 필요한 경우 브라우저 수준의 대체 방안을 수락할 수 있습니다.
• 더 넓은 생태계 정렬: PSD2와 같은 규제 요건, 특히 강력한 동적 링킹과 잘 부합합니다.

더 자세한 기술적 내용은 진행 중인 토론에서 확인할 수 있습니다: GitHub pull request #2020. 요약하자면, 확인 확장은 표준 패스키 기반 흐름의 마지막 주요 격차, 즉 사용자가 동의할 때 무엇을 보았는지에 대한 암호화 증명을 제공하는 것을 메울 수 있습니다. 비록 보안 결제 확인보다 덜 구조화되어 있기는 하지만 말입니다. 브라우저와 인증자 공급업체 사이에서 주목을 받게 된다면, PSD2 동적 링킹 및 그 이상에서 필요한 WYSIWYS 보안 보증을 제공하는 고도로 표준화된 방법이 될 수 있습니다.

SPC와 확인 확장은 WebAuthn에서 동적 링킹을 강화하려는 공통된 목표를 공유하지만, 범위와 접근 방식에서 차이가 있습니다. 아래 표는 이러한 차이점 중 일부를 강조합니다.

본질적으로, SPC는 포괄적인 결제 솔루션을 제공하려고 시도하며 흐름의 일부로 동적 링킹을 포함합니다. 반면, 확인 확장은 전체 결제 흐름을 강요하지 않고 표준 WebAuthn 메시지 내에서 _"보는 것이 서명하는 것"_이라는 요구사항을 해결합니다. 두 접근 방식 모두 PSD2 준수를 용이하게 할 수 있지만, 각각 실제적인 이점을 제공하기 위해서는 브라우저와 인증자의 지원에 의존합니다.

따라서 발급사, 은행 및 금융 기관에 대한 저희의 권장 사항은 어떤 사용 사례를 다루어야 하는지 신중하게 평가하고 생태계의 발전을 모니터링하는 것입니다. 패스키의 용이성은 기존 SCA 및 동적 링킹 솔루션에 UX 개선에 대한 상당한 압력을 가할 것이기 때문입니다. 고객들은 웹에서 생체 인증 솔루션을 요구하게 될 것입니다. 현재 저희의 운영 권장 사항은 다음과 같습니다.

• ✔️ 발급사/은행 웹사이트에서 시작된 결제를 위한 패스키: 패스키는 발급사/은행이 웹사이트 및 앱에 직접 동적 링킹을 구현하기에 매우 좋은 솔루션입니다. 고위험 결제에 대한 보안을 더욱 강화하기 위해 푸시 알림, 이메일/SMS OTP 또는 TOTP와 같은 다른 인증 옵션과 결합될 수 있습니다. 물론, SCA 준수 관련 고려 사항은 항상 이 논의의 일부가 되어야 합니다(저희의 패스키 및 SCA에 대한 4부작 시리즈 참조).

  제안된 솔루션은 패스키가 개방형 WebAuthn 표준을 기반으로 하므로 발급사/은행이 직접 구현할 수 있습니다. 그러나 이를 위해서는 상당한 노하우, 예외 사례 처리, 그리고 모든 새로운 규정 및 기술 발전에 대한 지속적인 최신 정보 유지가 필요합니다. 대안은 제3자 인증 제공업체를 사용하는 것입니다. 예를 들어, Corbado Connect는 조정된 WebAuthn 챌린지를 활용하여 거래 서명을 통한 동적 링킹을 지원합니다. 모든 정보는 감사 로그에 기록됩니다. 이는 금융 기관에 유용할 뿐만 아니라 모든 종류의 서명(예: 문서 서명, 고위험 사용자 작업)에 활용될 수 있습니다. 선택적으로 추가 SMS 또는 이메일 OTP를 사용하여 보안을 더욱 향상시킬 수 있습니다.

• ❌ 판매자 페이지에서의 결제를 위한 패스키: 판매자 페이지에서의 결제를 위해 패스키를 출시하는 것은 아직 불가능합니다. 교차 출처 사용 사례는 아직 개발 중이지만 2024년 말에는 실행 가능한 옵션이 될 수 있습니다. 하지만 판매자 페이지에서 인증을 위해 패스키를 사용하는 것은 이미 오늘날에도 훌륭한 아이디어이며, 향후 결제에도 사용할 수 있는 패스키를 수집하기 시작하는 데 사용될 수 있습니다.

• ❌ 동적 링킹을 위한 SPC 패스키 또는 확인 확장: SPC 표준은 아직 프로덕션 환경에서 사용될 만큼 성숙한 상태와 지원에 도달하지 못했습니다.

전반적으로 저희는 판매자와 은행이 표준에 참여하고 그들의 요구사항과 지원을 생태계에 추가하기 시작한 것을 기쁘게 생각합니다. 앞으로 금융 기관과 이커머스 플랫폼은 이러한 기술 발전을 면밀히 모니터링하고 패스키를 시스템에 통합하는 방법을 고려해야 합니다. 규제가 계속 진화함에 따라, 결제 인증 프로세스가 최신 보안 표준에 부합하고 전환율을 높이고 마찰을 줄이는 안전하고 효율적인 사용자 경험을 소비자에게 제공하도록 보장하며 앞서 나가는 것이 중요합니다.

패스키는 왜 중요한가요?

기업을 위한 패스키

비밀번호와 피싱은 기업을 위험에 빠뜨립니다. 패스키는 보안과 사용자 경험(UX)의 균형을 맞추는 유일한 MFA 솔루션입니다. 저희 백서에서 구현 방법과 비즈니스 영향을 확인해 보세요.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

동적 링킹을 위한 패스키를 검토해 보면, 패스키가 SCA 및 동적 링킹을 준수하는 데 도움이 될 수 있지만, 원래 자사 컨텍스트를 위해 설계된 WebAuthn 표준과의 제3자 서비스 기술 통합에는 몇 가지 과제가 있음이 분명합니다. 이러한 표준은 제3자 시나리오를 더 잘 지원하기 위해 점차 발전하고 있으며, 적용에 있어 더 큰 유연성을 향한 변화를 보여줍니다. 보안 결제 확인(SPC)은 이러한 적응을 더욱 발전시켜, 다양한 판매자 사이트에서 더 사용자 친화적이고 원활한 상호 작용을 통합하여 결제 인증 프로세스를 향상시키는 것을 목표로 합니다.

그러나 SPC 표준이나 확인 확장의 발전과 광범위한 수용은 주요 브라우저의 채택에 크게 의존하며, 이 과정은 느리게 진행되어 현재 Google Chrome이 유일한 지원자입니다. 이 느린 채택률은 더 많은 브라우저가 통합을 시작하지 않는 한 특히 SPC가 현재 상태를 벗어나는 것을 잠재적으로 방해할 수 있습니다. 패스키의 지속적인 개발과 증가하는 관심은 보안 엔클레이브, TEE, TPM과 같은 하드웨어 보안 모듈(HSM)에 의존하는 시스템이 결제 애플리케이션에 중요한 역할을 할 유망한 방향을 제시합니다. 이러한 기술은 은행 사이트에서 시작된 거래뿐만 아니라 제3자 판매자 플랫폼에서도 결제의 동적 링킹을 더 실용적이고 편리하게 만들 수 있는 향상된 보안을 제공하기 때문입니다.

패스키가 온라인 결제 프로세스로 유용성을 확장할 수 있는 잠재력은 웹 기반 거래를 보호하고 인터넷을 전반적으로 더 안전한 곳으로 만드는 데 중요한 측면을 강조합니다.