디지털 신원증명 및 결제: Apple 월렛 vs. Google 월렛 전략

디지털 결제는 끊임없이 변화하고 있습니다. 우리는 더 빠르고, 더 안전하며, 더 쉬운 결제 방식을 원합니다. 동시에 검증 가능한 신원증명(Verifiable Credentials, VC) 및 모바일 신분증(mdocs)과 같은 디지털 ID 도구도 발전하고 있습니다. 이러한 도구들은 사람들이 자신의 신원을 증명하는 새로운 방법을 제공합니다. 그렇다면 중요한 질문은 이것입니다. 이 새로운 디지털 ID가 디지털 결제를 훨씬 더 좋거나 간단하게 만들 수 있을까요?

이 글에서는 디지털 신원증명(ISO mdocs 및 OpenID4VC를 사용하여 전송되는 VC 포함)이 결제 세계와 어떻게 연결되는지 살펴봅니다. 다룰 내용은 다음과 같습니다.

• 현재 스마트폰 월렛(Apple Wallet, Google Wallet)이 ID 정보와 결제 카드를 어떻게 처리하는지.
• ISO 18013-5/7 mdocs와 같은 현재 디지털 ID 표준이 직접적인 결제 수단으로 적합하지 않은 이유.
• OpenID4VC와 같은 프로토콜이 미래의 결제 방식에서 어떤 역할을 할 수 있는지.
• 다른(서드파티) 월렛 앱이 결제 기능을 어떻게 처리할 수 있는지.
• 검증 가능한 신원증명을 결제 시스템에 사용하려고 할 때의 주요 문제점과 미래의 가능성.

이 글은 결제에만 초점을 맞춰 디지털 신원증명 및 패스키에 대한 다른 논의를 보완합니다.

디지털 신원증명이 결제에 어떻게 사용될 수 있는지 알아보려면, 먼저 오늘날의 주요 모바일 플랫폼과 내장된 월렛(Apple Wallet, Google Wallet)이 신원 정보와 결제 처리 방식을 어떻게 분리하여 관리하는지 이해해야 합니다.

네이티브 플랫폼 월렛은 사용자를 위한 정교한 허브가 되었지만, 일반적으로 신원 증명과 결제 수단 사이에는 명확한 구분을 유지합니다.

• 신원 증명(예: mDL):
  • Apple Wallet: 주로 ISO/IEC 18013-5를 준수하는 모바일 운전면허증(mDL) 및 주 신분증을 지원합니다. WWDC25에서 Apple은 Safari 26(iOS 26 탑재)이 온라인 제시를 위해 W3C Digital Credentials API를 지원할 것이며, org.iso.mdoc 프로토콜에만 독점적으로 초점을 맞출 것이라고 확인했습니다. 이는 결제가 아닌 신원 속성(예: 이름, 나이, 주소)을 확인하기 위한 것입니다.
  • Google Wallet 및 Android Credential Manager: Google Wallet도 ISO 18013-5 기반의 mDL을 지원합니다. 그 기반이 되는 Android Credential Manager는 더 유연한 프레임워크를 제공합니다. Digital Credentials API 구현은 프로토콜에 구애받지 않지만, Android는 전송 메커니즘으로 OpenID4VP를 사용하는 기본 구현을 제공합니다.
• 결제 수단(예: 신용/직불 카드):
  • Apple Pay(Apple Wallet 내)와 Google Pay(Google Wallet 내)는 모두 확립되고 고도로 규제된 결제 기술을 활용합니다. 이는 주로 EMV(Europay, Mastercard, Visa) 표준에 기반하며, 토큰화(거래 시 실제 카드 번호를 대체하는 기기 PAN 또는 DPAN), 결제 토큰 저장을 위한 보안 요소 또는 하드웨어 기반 보안, 거래 보안을 위한 동적 암호문을 포함합니다.
  • 이러한 결제 시스템은 기존 결제 네트워크(Visa, Mastercard, Amex 등) 및 매입 은행과 직접 상호 작용합니다.

핵심 요약: 네이티브 플랫폼 월렛은 현재 신원 증명과 결제 카드에 대해 별도의 "스택" 또는 기술로 운영됩니다. mdoc은 신원 속성을 증명하기 위해 제시되고, 토큰화된 카드는 결제를 위해 제시됩니다. 이러한 네이티브 생태계 내에서 mdoc을 결제 수단으로 직접 사용하는 경우는 없습니다.

ISO/IEC 18013-5 표준은 mDL 및 기타 모바일 ID(mdoc)의 데이터 구조를 정의합니다. 신원 확인에는 훌륭하지만, 그 설계는 직접적인 결제 수단으로 사용하기에는 부적합합니다.

ISO 18013-5가 사용자 지정 네임스페이스를 허용하므로 이론적으로 mdoc에 PAN이나 결제 토큰을 담을 사용자 지정 데이터 필드를 추가할 수 있더라도, mdoc 표준 자체는 다음을 정의하지 않습니다.

• 동적 결제 암호문을 생성하거나 처리하는 방법.
• 결제 네트워크와 온라인 승인을 수행하는 방법.
• 결제 거래에 특정한 필수 보안 메커니즘(신원 데이터 무결성을 넘어서).

따라서 현재로서는 ISO 18013-5 mdoc을 직접적인 결제 수단으로 사용할 방법이 없습니다.

mdoc은 결제 도구는 아니지만, 고위험 활동에 대해 사용자의 신원을 명시적으로 확인해야 하는 "단계별 인증" 흐름에서 역할을 할 수 있습니다. 이는 결제 자체를 실행하는 데 사용하는 것과는 구별됩니다. 흐름은 일반적으로 다음과 같습니다.

1. 기본 인증: 사용자는 서비스에 로그인하며, 종종 패스키와 같은 마찰이 적은 방법을 사용합니다.
2. 단계별 인증 트리거: 거액의 은행 송금, 개인 정보 업데이트 등 높은 보증 수준이 요구되는 활동에 대해 서비스는 명시적인 신원 확인을 요구합니다.
3. mdoc 제시: 서비스는 사용자의 mdoc(예: 운전면허증) 제시를 요청합니다. 사용자는 자신의 월렛에서 필요한 속성을 제시합니다.
4. 검증: 서비스는 신뢰할 수 있는 출처 또는 이전에 등록된 신원과 대조하여 mdoc 데이터를 암호학적으로 검증합니다.

이 모델에서 mdoc은 특정 고위험 순간에 대해 강력하고 피싱에 강한 신원 증명을 제공합니다. 그러나 뒤따르는 금융 거래는 여전히 기존의 결제 레일을 사용합니다. mdoc은 _결제 수단_이 아닌 _사람_을 확인합니다.

mdocs 자체는 결제 수단이 아니지만, OpenID for Verifiable Credentials(OpenID4VC – 제시를 위한 OpenID4VP와 발급을 위한 OpenID4VCI 포함)와 같은 프로토콜은 더 유연한 전송 계층을 제공합니다.

OpenID4VC의 주요 특징:

• 페이로드가 아닌 프로토콜: OID4VC는 VC를 요청하고 제시하는 방법을 정의하지만, VC 페이로드 자체의 형식에 대해서는 대체로 구애받지 않습니다. mdoc, W3C 표준 VC(예: JWT 또는 SD-JWT 형식) 또는 기타 사용자 지정 신원증명 유형을 전송할 수 있습니다.
• 광범위한 사용 사례: 이러한 유연성 덕분에 Android(Credential Manager를 통해)와 같은 플랫폼은 공통 메커니즘을 통해 다양한 유형의 신원증명 요청을 지원할 수 있습니다.
• 결제 VC에 대한 미래 호환성: 만약 결제 업계가 검증 가능한 "결제 토큰" 또는 "결제 승인" 신원증명 형식을 표준화한다면, OID4VC는 이론적으로 사용자의 월렛과 가맹점/PSP 간에 이러한 신원증명을 전송할 수 있습니다.

그러나 OID4VC 자체는 결제 솔루션이 아닙니다:

• OID4VC의 역할은 신원증명 교환을 용이하게 하는 것입니다. 결제 신원증명의 내용, 보안 기능 또는 결제 처리 시스템과의 상호 작용 방식을 정의하지는 않습니다.
• OID4VC가 결제에 유용하려면, 널리 채택되고 안전하며 표준화된 _검증 가능한 결제 신원증명 형식_이 먼저 개발되어 결제 생태계(발급사, 매입사, 네트워크)의 지원을 받아야 합니다. 현재로서는 이러한 것이 존재하지 않습니다.

네이티브 플랫폼 월렛 외에도 서드파티 월렛(예: EUDI 월렛, 은행 제공 월렛, 특정 산업용 월렛) 생태계가 성장하고 있습니다. 이러한 월렛은 특히 결제 맥락에서 빠르고 마찰이 적은 인증과 높은 보증 수준의 속성 확인 사이의 근본적인 차이를 잘 헤쳐나가야 합니다.

새롭게 부상하는 공감대는 패스키가 결제 서비스에 대한 핵심 _인증_에 이상적이라는 것입니다. 패스키는 피싱에 강하고 원활한 사용자 경험을 위해 설계되었기 때문입니다. 중요한 결제 확인 단계에 디지털 신원증명 제시를 끼워 넣으면 상당한 마찰을 더하고 전환율에 해를 끼칠 가능성이 높습니다. 따라서 디지털 신원증명의 주요 역할은 거래 자체가 아니라, 결제 기능을 활성화하는 일회성의 높은 보증 수준의 온보딩 및 KYC 단계에 있습니다. 이러한 월렛은 특히 디지털 신원 기능과 함께 결제를 어떻게 처리할까요?

서드파티 월렛이 결제를 승인하려면 가맹점의 앱이나 웹사이트에서 호출될 방법이 필요합니다. 이를 위한 몇 가지 확립된 상호 작용 모델이 있으며, 각각 플랫폼 통합 및 사용자 경험 수준이 다릅니다.

• 앱 간 딥 링킹: 이는 가맹점의 애플리케이션(네이티브 또는 웹)이 사용자 지정 URL 스킴(예: eudi-wallet://...)을 사용하여 사용자를 서드파티 월렛 앱으로 리디렉션하는 보편적인 방법입니다. 거래 세부 정보는 URL의 매개변수로 전달됩니다. 사용자가 월렛 앱에서 결제를 확인하면 다른 딥 링크를 사용하여 가맹점 앱으로 다시 리디렉션됩니다. 이는 iOS와 Android 모두에서 작동하지만 앱 간에 눈에 띄는 컨텍스트 전환이 포함됩니다.
• 네이티브 월렛 선택: 네이티브 월렛 선택을 사용하면 애플리케이션이 등록된 모든 결제 핸들러나 월렛을 표시하는 일반 시스템 서비스를 호출할 수 있습니다. 그러면 사용자는 시스템이 제공하는 UI에서 선호하는 월렛을 선택할 수 있습니다. 이는 단순한 딥 링킹(Digital Credential API)보다 더 통합된 느낌을 줍니다.
• 간단한 QR 코드 기반 결제: 이 모델은 데스크톱에서 모바일로의 흐름에 이상적입니다. 가맹점의 웹사이트는 거래 세부 정보나 URL이 포함된 QR 코드를 표시합니다. 사용자는 모바일 월렛 앱으로 이 코드를 스캔하고, 앱은 휴대폰에서 독립적으로 확인을 처리합니다. 그런 다음 월렛의 백엔드는 승인 사실을 가맹점 시스템에 다시 전달합니다.
• 표준화된 교차 기기 흐름(FIDO CTAP): QR 코드 방식의 진화된 형태로, FIDO의 클라이언트-인증기 프로토콜(CTAP)과 같은 프로토콜을 사용하여 데스크톱 브라우저(클라이언트)와 모바일 월렛(인증기 역할) 간에 직접적이고 안전하며 암호화된 채널을 생성합니다. 브라우저와 휴대폰이 직접 통신하므로 단순한 QR 코드보다 더 안전하며, Google이 패스키와 디지털 신원증명 모두에 대해 강력하게 지원하는 모델입니다.
• 직접 백엔드 통합: 일부 폐쇄 루프 시스템에서는 서드파티 월렛 앱이 결제 서비스 제공업체(PSP) 또는 금융 기관의 백엔드와 직접 상호 작용하여 종종 독점 API를 사용하여 결제를 처리할 수 있습니다.

이러한 모델은 결제 확인을 시작하기 위한 "전송 계층"을 제공하며, 그 안에서 (EUDI 월렛에 대해 자세히 설명된 것과 같은) 암호화 흐름이 발생할 수 있습니다.

WWDC25에서의 발표로 브라우저가 디지털 신원증명을 처리하는 방식에 대한 그림이 훨씬 명확해졌으며, 신원 확인과 결제 처리 간의 분리가 확고해졌습니다. 플랫폼들은 서드파티 월렛이 W3C Digital Credentials API를 통해 _신원 확인_을 위해 브라우저와 상호 작용할 수 있도록 하고 있지만, 접근 방식은 갈라지고 있습니다.

• Apple의 입장(WWDC25에서 확인): Apple은 Safari 26(iOS 26과 함께 제공)에서 Digital Credentials API 지원을 공식 발표했습니다. 그들의 "웹에서 신분증 확인하기" 세션에서 자세히 설명했듯이, 이 구현은 org.iso.mdoc 프로토콜만 독점적으로 지원합니다. 이를 통해 웹사이트는 Apple Wallet이나 다른 등록된 서드파티 문서 제공 앱에서 검증 가능한 정보를 요청할 수 있지만, 더 범용적인 OpenID4VP 프로토콜은 지원하지 않습니다. 디지털 신원증명에 대한 지원이 증가하고 웹 통합이 강화됨에 따라 시스템 성능과 보안을 유지하는 것이 더욱 중요해집니다. CleanMyMac과 같은 도구는 이러한 기술이 발전함에 따라 Mac이 원활하게 실행되도록 돕습니다.
• Google의 입장: Android의 Credential Manager는 서드파티 월렛이 신원증명 요청 핸들러로 등록할 수 있도록 합니다. Chrome에서의 Digital Credentials API 구현은 OpenID4VP를 주요 전송 프로토콜로 사용하는 데 중점을 둡니다. OpenID4VP가 mdoc을 페이로드로 전달할 수 있지만, 프로토콜 자체는 Apple의 직접적인 org.iso.mdoc 접근 방식과 다릅니다.

중요한 점은 이러한 브라우저 통합이 제시된 mDoc이나 VC를 결제 수단으로 취급하기 위한 것이 아니라 신원 속성을 위한 것이라는 점입니다.

사용자가 브라우저의 Digital Credentials API를 통해 월렛에서 mDL을 웹사이트에 제시하면, 해당 웹사이트는 결제 중 주소 자동 채우기나 연령 확인에 이 정보를 사용할 수 있습니다. 그러나 실제 결제 단계는 여전히 결제 수단(예: Apple Pay, Google Pay 또는 카드 정보 입력)과의 별도 상호 작용이 필요합니다. 브라우저 API 자체는 신원 증명을 사용하여 금융 거래를 시작하거나 처리하도록 설계되지 않았습니다.

EU 디지털 신원(EUDI) 월렛은 서드파티 월렛이 운영 체제와 API 가용성의 복잡하고 실제적인 환경을 어떻게 헤쳐나가야 하는지를 보여주는 훌륭한 사례 연구입니다. 여러 기능 중에서도 신원 확인과 결제 확인이 가장 두드러진 두 가지 사용 사례이며, 이 두 가지 작업을 수행하는 기술적 경로는 특히 Android의 유연한 프레임워크와 Apple의 더 경직된 구현을 비교할 때 다릅니다.

다음 표는 EUDI 월렛이 신원 확인 또는 결제 승인을 위해 어떻게 호출될 수 있는지 분석하고 플랫폼 간의 다른 지원을 강조합니다.

비교에서 얻은 핵심 요약:

• Digital Credentials API: 이 새롭게 부상하는 W3C 표준은 프로토콜에 구애받지 않으며 양 플랫폼에서 신원 확인에 잘 지원됩니다. 구현을 위해 Android는 다양한 신원증명 형식을 전달할 수 있는 유연한 OpenID4VP 프로토콜을 사용하는 기본 흐름을 제공합니다. 반면 Apple의 구현은 org.iso.mdoc 형식에 엄격하게 국한됩니다. 결정적으로, 브라우저는 이 API의 범위를 결제 시작이 아닌 신원 사용 사례로 한정합니다.
• 네이티브 월렛 선택기: 두 운영 체제 모두 월렛을 선택할 수 있는 네이티브 UI를 제공하지만, 제한 사항이 다릅니다. Android는 신원 및 결제 앱 모두에 대한 선택기를 제공합니다. iOS는 등록된 신원 "문서 제공자" 앱에 대한 선택기를 제공하지만 서드파티 결제 앱에 대한 선택기는 제공하지 않습니다.
• 앱 간 딥 링킹: 이것은 양 플랫폼에서 신원 및 결제 사용 사례 모두에 대해 안정적으로 작동하는 보편적인 해결사입니다. iOS에서 서드파티 월렛을 결제용으로 호출하는 주요 방법으로 남아 있습니다.
• 표준화된 교차 기기: 이 FIDO CTAP 기반 흐름은 현재 Google/Android 생태계의 기능이며 iOS에서는 지원되지 않습니다.

(*) DC API를 통한 결제 참고: Android가 OpenID4VP를 사용하므로 Digital Credentials API를 통해 결제 흐름이 기술적으로 가능하지만, 이것이 주요 설계 초점은 아닙니다. 다른 네이티브 방법과 달리 이 특정 API를 통한 원활한 결제 통합은 아직 지켜봐야 하며 브라우저 공급업체의 명시적인 지원이 필요합니다.

이 비교를 통해 신원 확인은 Digital Credentials API를 통해 점점 더 표준화되고 있지만, EUDI 월렛과 같은 서드파티 월렛의 결제 승인은 특히 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 토큰 서비스 또는 Mastercard MDES 등)과 비교하는 것입니다.

• 결제 토큰화는 민감한 기본 계정 번호(PAN)를 보안 토큰과 일회용 암호문으로 대체했습니다. 이는 거래 중 핵심 자산인 카드 번호를 보호합니다.
• 검증 가능한 신원증명은 토큰화가 PAN에 했던 역할을 개인 데이터에 대해 수행하는 것을 목표로 합니다. 사용자는 원시 데이터(이름, 생년월일, 주소)를 공유하는 대신 신뢰할 수 있는 발급 기관의 암호학적으로 서명된 신원증명을 제시합니다.

본질적으로, VC는 개인 데이터에 대해 결제 토큰과 암호문이 카드 데이터에 대해 갖는 의미와 같습니다: 위험을 줄이고 개인 정보를 강화하는 안전하고 검증 가능한 대체 수단입니다.

이러한 유사점을 바탕으로 업계 단체들은 "검증 가능한 결제 신원증명" 개념을 연구하고 있습니다. 이는 은행이 발급한 신원증명으로, 결제 수단(토큰화된 카드 등)을 패키징하여 거래 승인에 사용할 수 있습니다.

• 보안 결제 표준 기구인 EMVCo는 FIDO 표준을 EMV 3-D Secure 프로토콜에 적극적으로 통합하고 있습니다. 이를 통해 이전 패스키 인증을 마찰 없는 승인을 위한 강력한 신호로 사용할 수 있으며, 동시에 보안 결제 확인(SPC)이 기존 OTP 방식의 현대적이고 피싱에 강한 대안으로 기능하도록 준비하고 있습니다. 또한 검증 가능한 신원증명이 향후 이러한 흐름에 어떻게 통합될 수 있는지에 대한 논의도 진행 중입니다.
• Visa는 FIDO 인증기를 결제 신원증명에 안전하게 바인딩하는 Visa Payment Passkey Service를 발표했습니다. 이 서비스는 결제 경험을 중단하지 않고 단일의 마찰 없는 단계로 신원을 확인하고 결제를 승인하도록 설계되었습니다.
• Mastercard는 Mastercard Payment Passkey Service로 유사한 전략을 따르고 있습니다. 이 서비스는 토큰 인증 서비스(TAS)를 활용하여 비밀번호와 OTP를 패스키 기반 생체 인증으로 대체하며, 토큰화 서비스(MDES)와 긴밀하게 통합됩니다.

이는 업계가 월렛이 단일의 표준화된 흐름으로 신원과 결제 승인에 대한 암호학적으로 검증 가능한 증명을 제시할 수 있는 미래로 나아가고 있음을 명확히 보여줍니다.

이러한 혁신의 상당 부분은 강력한 규제 순풍, 특히 유럽 연합으로부터 가속화되고 있습니다.

EU의 eIDAS 2.0 규정은 시민에게 디지털 ID를 제공하는 것뿐만 아니라, EUDI 월렛을 온라인 결제를 위한 SCA 수행 방법으로 명시적으로 구상하고 있습니다. 이는 미래에 EU의 은행 및 결제 제공업체가 사용자가 온라인 거래를 확인하는 방법으로 EUDI 월렛을 수락해야 할 수도 있음을 의미하며, 독점적인 은행 앱이나 SMS 코드에 대한 표준 기반 대안을 제공합니다.

EU에서의 획기적인 독점 금지 합의는 이미 Apple이 이전에 폐쇄했던 아이폰의 NFC 인터페이스를 개방하도록 강제했습니다. iOS 17.4(2024년 3월 5일 출시)부터 Apple은 필요한 API를 구현하고 사용자가 기본 비접촉 결제 앱을 선택할 수 있도록 허용하여 유럽 위원회의 구속력 있는 마감일인 2024년 7월 25일을 준수했습니다. 이것은 더 이상 미래의 전망이 아니라 유럽 경제 지역(EEA)의 현재 현실입니다.

이러한 변화는 서드파티 월렛 앱이 이제 iOS에서 자체 탭투페이(tap-to-pay) 솔루션을 제공할 수 있게 되어 Apple Pay의 오랜 독점을 종식시켰음을 의미합니다. 이제 개발자가 사용할 수 있는 주요 기능은 다음과 같습니다.

• 기본 월렛 선택: EEA 내 사용자는 적격한 서드파티 앱을 기본 비접촉 결제 애플리케이션으로 설정할 수 있으며, 이는 측면 버튼을 두 번 클릭하여 호출할 수 있습니다.
• 완전한 통합: 이러한 월렛은 Face ID 및 Touch ID를 포함한 아이폰의 네이티브 보안 기능을 결제 승인에 사용할 수 있습니다.
• 실제 도입: 노르웨이의 Vipps MobilePay와 독일의 PayPal을 포함한 여러 주요 업체들이 이미 솔루션을 출시했습니다.

이 개방의 의미는 중요하며 이미 전개되고 있습니다.

• 경쟁 심화: 은행과 핀테크는 이제 Apple Pay와 자체 플랫폼에서 직접 경쟁할 수 있게 되어 발급 기관 수수료를 낮추고 혁신을 촉진할 것으로 예상됩니다.
• 더 넓은 신원증명 사용: 동일한 API를 결제뿐만 아니라 기업 배지, 대중교통 패스, 호텔 키 등 Apple Wallet에 있을 필요 없이 더 많은 용도로 사용할 수 있습니다.
• 표준화된 신원증명을 위한 경로: 이는 중요한 선례를 남깁니다. 결제 앱을 위해 NFC 인터페이스를 개방한 동일한 규제 논리가 결국 EUDI 월렛용으로 시범 운영 중인 것과 같은 표준화되고 중립적인 "검증 가능한 결제 신원증명"에 대한 지원을 의무화하는 데 사용될 수 있으며, 이를 통해 독점 솔루션과 함께 작동할 수 있습니다.
• 글로벌 선례: 이 변화는 현재 EEA에 국한되어 있지만 강력한 글로벌 선례를 남깁니다. 미국을 포함한 다른 지역의 규제 당국이 면밀히 주시하고 있으며, 이는 전 세계적으로 유사한 개방을 가속화할 수 있습니다.

결제 발급 기관(은행, 카드사, 핀테크)에게 디지털 신원증명으로의 전환을 헤쳐나가기 위해서는 실용적이고 단계적인 전략이 필요합니다. 목표는 오늘날 통제하는 자산을 기반으로 내일의 생태계를 준비하는 것입니다. 이 플레이북은 즉각적이고 후회 없는 조치에서부터 더 전략적이고 장기적인 평가에 이르기까지 그 전략을 개괄합니다.

미래 월렛 전략의 기반은 안전하고 널리 채택된 네이티브 앱입니다. 즉각적인 우선순위는 앱의 도달 범위를 극대화하고 로그인과 결제 모두에 대한 인증을 강화하는 것입니다.

1. 네이티브 앱 채택 추진: 귀사의 모바일 앱이 미래의 월렛입니다. 주요 목표는 고객에게 없어서는 안 될 도구로 만드는 것입니다. 이러한 배포와 참여는 향후 모든 신원증명 발급 또는 월렛 기능의 중요한 기반이 됩니다.

2. PayPal 모델에 따라 결제에 패스키 사용: 로그인을 넘어 결제 승인을 위해 즉시 패스키를 배포하십시오. Apple Pay와 같은 네이티브 플랫폼 솔루션과 거의 동등한 경험을 목표로 하십시오. 강력한 고객 인증(SCA)이 요구되는 규제 환경에서는 PayPal의 실용적인 접근 방식을 채택하십시오.

   • 패스키를 주요 인증 요소로 활용합니다.
   • 이를 신뢰할 수 있는 기기 신호(예: 앱 또는 보안 쿠키를 통해 관리되는 "기억된 기기")와 결합하여 SCA의 "소유" 요소를 충족시킵니다.
   • 이 조합을 통해 보편적인 VC 지원을 기다리지 않고도 매우 안전하고 규정을 준수하며 원활하고 마찰이 적은 결제 확인 경험을 제공할 수 있습니다.

패스키로 보호되는 안전한 앱을 기반으로, 명확한 가치를 제공하는 곳에 새로운 신원증명 기술을 선택적으로 통합하기 시작할 수 있습니다.

3. 검증 가능한 결제 신원증명의 부상 주시: 결제 토큰을 담고 있는 VC의 개념은 강력하지만 아직 표준화되지 않았습니다. 여기서 귀사의 역할은 적극적인 관찰자이자 참여자가 되는 것입니다.

   • 조치: EMVCo 및 W3C와 같은 표준 기구 내의 진행 상황을 면밀히 추적하십시오. 표준화된 검증 가능한 결제 신원증명이 기존 패스키 기반 흐름보다 명확한 이점을 제공할 경우 이를 활용할 준비를 하십시오.

4. 신원 사용 사례에 디지털 신원증명 통합: EUDI 월렛과 같은 디지털 신원 월렛이 주목받기 시작하면, 결제가 아닌 신원 관련 작업을 위해 Digital Credentials API를 통합하십시오.

   • 조치: VC 제시가 뛰어난 성능을 발휘하는 높은 보증 수준의 프로세스에 사용하십시오.
     • 온보딩 및 KYC: 신규 계정 설정을 간소화합니다.
     • 단계별 인증: 고위험 활동에 대한 신원을 확인합니다.
     • 계정 복구: 기기를 분실한 사용자를 위한 안전한 경로를 제공합니다.

모든 새로운 결제 기술 채택의 궁극적인 장벽은 사용자 마찰입니다. 간단한 패스키 흐름을 대체하기 전에 VC 기반 대안은 더 안전할 뿐만 아니라 똑같이 원활하다는 것을 증명해야 합니다.

5. 원클릭 경험과 끊임없이 비교 평가: 현대적인 결제 경험의 표준은 Apple Pay와 웹에서 그 뒤를 잇는 PayPal과 같은 선두 주자에 의해 설정됩니다. 도입하는 모든 새로운 흐름은 거의 즉각적인 원클릭 확인과 경쟁해야 합니다. 현재 모든 신호는 대다수의 거래에서 패스키의 피싱 저항성이 충분한 수준의 보호와 우수한 사용자 경험을 제공함을 나타냅니다. 결제 흐름에 눈에 띄는 마찰을 유발한다면 VC 제시 단계를 추가하지 마십시오.

6. WebAuthn 내 인밴드 기기 신호 주시: 패스키의 진화는 정적이지 않습니다. 기기별 신호를 제공하려는 초기 시도는 중단되었지만, 표준 기구들은 더 강력한 기기 바인딩 신뢰 신호를 WebAuthn 프로토콜에 직접 통합하기 위해 적극적으로 노력하고 있습니다. 이를 통해 RP는 패스키 인증 중에 신뢰할 수 있는 기기를 식별하여 별도의 아웃오브밴드 VC 제시 없이 위험 엔진에 대한 신호를 더욱 강화할 수 있습니다. 이는 패스키의 마찰 없는 경험을 희생하지 않으면서 보안을 강화할 가능성이 가장 높은 경로이므로 이 분야를 면밀히 주시하십시오.

이 단계별 플레이북을 따르면, 발급 기관은 오늘날 보안을 극대화하고 사용자 경험을 향상시키는 동시에 내일의 검증 가능한 결제 기술을 신중하게 채택할 준비를 하는 강력하고 실용적인 전략을 구축할 수 있습니다.

디지털 신원증명이 단순히 KYC를 지원하거나 결제 계정에 사용자를 인증하는 것을 넘어 결제 프로세스의 핵심 부분이 되려면 몇 가지 중요한 과제를 해결해야 합니다.

1. 결제 전용 VC의 표준화: 결제를 위한 전용의 안전하고 널리 인정받는 검증 가능한 신원증명 형식이 개발되어야 합니다. 이는 결제 토큰, 거래별 데이터, 잠재적으로 동적 보안 요소를 포함해야 하며, 현재의 신원 중심 mdoc이나 일반 VC의 범위를 훨씬 뛰어넘습니다.
2. 결제 네트워크와의 통합: 모든 VC 기반 결제 솔루션은 기존 글로벌 결제 네트워크(Visa, Mastercard 등)와 원활하게 통합되거나 실행 가능한 새로운 레일을 제안해야 합니다. 여기에는 복잡한 기술, 보안 및 비즈니스 모델 조정이 포함됩니다.
3. 규제 준수: 결제는 엄격하게 규제됩니다(예: 유럽의 PSD2/SCA, 전 세계적으로 PCI DSS). VC 기반 결제 시스템은 보안, 소비자 보호, 사기 방지 등 모든 관련 금융 규정을 충족해야 합니다.
4. 발급사 및 매입사 채택: 은행, 금융 기관(결제 VC의 발급사로서) 및 가맹점 매입사는 이러한 시스템을 지원하기 위해 인프라에 투자해야 합니다.
5. 보안 모델: 결제 VC를 위한 강력한 보안 모델이 필수적이며, 금융 맥락에서 발급, 저장(이상적으로는 하드웨어 기반 보안 요소에), 제시 및 폐지를 다루어야 합니다.
6. 사용자 경험: VC는 사용자 제어를 제공할 수 있지만, 광범위한 채택을 얻으려면 결제 경험이 빠르고 직관적이며 신뢰할 수 있어야 합니다.

미래 가능성:

• 결제 승인 전표로서의 VC: VC는 연결된 계좌에서 지불할 수 있는 암호학적으로 서명된 "승인"을 나타낼 수 있으며, OpenID4VP를 통해 제시되고 실제 자금 이체는 여전히 전통적인 레일을 통해 발생합니다.
• 결제 토큰을 포함하는 VC: 결제 토큰(EMV DPAN과 유사)을 안전하게 보관하도록 표준화된 VC를 정의할 수 있으며, 이는 기존 결제 인프라에서 처리됩니다.
• 폐쇄 루프 결제 VC: 특정 발급사나 커뮤니티는 자체 폐쇄 루프 시스템 내에서 결제를 위한 VC를 생성할 수 있습니다.

그러나 현재로서는 대부분 개념적인 수준입니다. 현재 VC 및 mdoc 개발의 주요 동력은 브라우저 API의 구체적인 구현으로 더욱 확고해졌으며, 여전히 결제 실행이 아닌 신원 확인 및 속성 증명에 초점을 맞추고 있습니다.

디지털 신원과 결제의 융합은 복잡하지만 헤쳐나갈 수 있는 환경을 제시합니다. 단일의 보편적인 "검증 가능한 결제 신원증명"의 약속은 매력적이지만, 이 글은 오늘날 결제 발급 기관을 위한 가장 효과적이고 실용적인 전략이 다른 현실에 기반을 두고 있다는 결론을 내립니다: 최고의 사용자 경험을 위한 싸움이 가장 중요하며, 패스키가 가장 강력한 무기입니다.

전략적 플레이북은 명확합니다. 즉각적이고 후회 없는 조치는 탁월한 네이티브 앱을 구축하는 데 집중하고, 이를 Apple Pay와 PayPal이 설정한 마찰 없는 "원클릭" 표준에 필적할 수 있는 패스키 기반 결제를 배포하는 수단으로 사용하는 것입니다. 이 접근 방식은 성숙하고 널리 채택된 기술을 사용하여 오늘날 보안(피싱 저항성을 통해)과 사용자 경험의 핵심 요구 사항을 해결합니다.

이 모델에서 검증 가능한 신원증명은 중요하지만 별개의 역할을 찾습니다. 아직 결제 행위 자체를 위한 도구는 아니지만, 안전한 온보딩, 강력한 계정 복구, 규제 KYC와 같이 이를 둘러싼 높은 보증 수준의 신원 작업에 없어서는 안 될 존재입니다.

결제의 미래는 단일 기술에 의해 결정되는 것이 아니라 사용자에 대한 끊임없는 집중으로 결정될 것입니다. 성공은 자신의 앱에서 패스키 기반 경험을 먼저 마스터하고, 검증 가능한 신원증명과 인밴드 패스키 신뢰 신호의 진화를 신중하게 모니터링하는 발급 기관에게 올 것입니다. 그들은 이러한 새로운 기술을 단지 사용 가능할 때가 아니라, 진정으로 원활하고 안전하며 우수한 결제 경험이라는 강력한 벤치마크를 충족할 수 있을 때만 통합할 준비가 되어 있어야 합니다.