डायनेमिक लिंकिंग में बायोमेट्रिक्स और Payer Awareness

Corbado का दृष्टिकोण फ़िशिंग-प्रतिरोधी पासकीज़ (SCA) को बैंक-नियंत्रित डिस्प्ले और सर्वर-साइड डायनेमिक लिंकिंग के साथ जोड़ता है ताकि PSD2 RTS अनुच्छेद 5 ("जो-आप-देखते-हैं-वही-आप-साइन-करते-हैं") को पूरा किया जा सके।

• मुख्य कार्यान्वयन (आज): हम पासकी ऑथेंटिकेशन से ठीक पहले और उसके दौरान एक Bison-Bank-नियंत्रित UI में ट्रांज़ैक्शन की राशि और प्राप्तकर्ता दिखाते हैं। हमारा बैकएंड एक वन-टाइम चैलेंज जेनरेट करता है जो एक कैनॉनिकलाइज़्ड ट्रांज़ैक्शन स्नैपशॉट (राशि, प्राप्तकर्ता, txnId) से बाध्य होता है। प्रतिक्रिया केवल तभी स्वीकार की जाती है जब वह उस स्नैपशॉट से मेल खाती है; कोई भी बदलाव इसे अमान्य कर देता है।

• नियामक स्थिति: पासकीज़ के साथ भी रिमोट पेमेंट्स के लिए डायनेमिक लिंकिंग आवश्यक है (PSD2 अनुच्छेद 97(2); RTS अनुच्छेद 5)। RTS को यह आवश्यक नहीं है कि डायनेमिक-लिंकिंग "ऑथेंटिकेशन कोड" डिवाइस पर कंप्यूट किया जाए; सर्वर-साइड जेनरेशन/वैलिडेशन स्वीकार्य है जब डिस्प्ले की अखंडता, विशिष्टता और बदलाव पर अमान्यकरण लागू किया जाता है (यह भी देखें EBA Q&A 2020_5366 कि कोड कहाँ कंप्यूट किया जा सकता है)।

• सुरक्षा और ऑडिटेबिलिटी: एक हार्डवेयर-एंकर, फ़िशिंग-प्रतिरोधी पासकी सिग्नेचर को विशिष्ट ट्रांज़ैक्शन डेटा से बाइंड करना छेड़छाड़ और रिले को रोकता है, और भुगतानकर्ता की सहमति का मजबूत, गैर-अस्वीकार्य सबूत देता है। जहां समर्थित हो, हम बैकएंड मॉडल को बदले बिना प्रदर्शित विवरणों का क्रिप्टोग्राफ़िक प्रमाण जोड़ने के लिए वैकल्पिक रूप से Secure Payment Confirmation (SPC) को अपना सकते हैं।

• SCA: अलग-अलग श्रेणियों (ज्ञान/अधिकार/स्वामित्व) से दो स्वतंत्र तत्व, जो उचित शमन (RTS अनुच्छेद 6-8) के साथ प्रकटीकरण/प्रतिकृति के खिलाफ संरक्षित हैं। स्वतंत्रता आवश्यक है (अनुच्छेद 9), जिसमें बहु-उद्देश्यीय उपकरणों पर निष्पादित होने पर अलगाव भी शामिल है (जैसे, OS-स्तरीय सुरक्षा, सुरक्षित हार्डवेयर)।
• डायनेमिक लिंकिंग (RTS अनुच्छेद 5):
  • (i) भुगतानकर्ता को ऑथेंटिकेशन के दौरान राशि और प्राप्तकर्ता के बारे में पता होता है
  • (ii) ऑथेंटिकेशन कोड उस राशि/प्राप्तकर्ता के लिए अद्वितीय होता है
  • (iii) कोई भी बदलाव कोड को अमान्य कर देता है
  • (iv) राशि, प्राप्तकर्ता और कोड की गोपनीयता/अखंडता एंड-टू-एंड संरक्षित होती है। यह नियामक "जो-आप-देखते-हैं-वही-आप-साइन-करते-हैं" के इरादे को पूरा करता है।
• निहितार्थ: केवल मजबूत यूज़र ऑथेंटिकेशन पेमेंट्स के लिए अपर्याप्त है। अनुमोदन को विशिष्ट ट्रांज़ैक्शन डेटा से बाइंड किया जाना चाहिए, जिसमें बाइंडिंग और भुगतानकर्ता को डिस्प्ले का ऑडिट योग्य सबूत हो (RTS अनुच्छेद 5(1)(a–d))।

स्पष्टीकरण — फ़िशिंग बनाम ऑथराइज़ेशन: पासकीज़ ऑरिजिन-बाउंड होते हैं, इसलिए नकली डोमेन मान्य सिग्नेचर प्राप्त नहीं कर सकते। हालाँकि, PSD2 को अभी भी रिमोट पेमेंट्स के लिए डायनेमिक लिंकिंग की आवश्यकता है ताकि ऑथराइज़ेशन को सटीक राशि और प्राप्तकर्ता से बाइंड किया जा सके, किसी भी बदलाव को अमान्य किया जा सके और भुगतानकर्ता को जो दिखाया गया है उसकी अखंडता की रक्षा की जा सके (RTS अनुच्छेद 5(1)(a–d))। डायनेमिक लिंकिंग केवल फ़िशिंग को ही नहीं, बल्कि ऑथराइज़ेशन की अखंडता (MITM/MITB/TPP प्रतिस्थापन सहित) को भी संबोधित करती है।

EBA 2019 की राय (EBA‑Op‑2019‑06) इस बात को पुष्ट करती है कि डायनेमिक लिंकिंग ऑथेंटिकेशन को राशि और प्राप्तकर्ता से बाइंड करती है, कारकों की स्वतंत्रता की आवश्यकता होती है और डिवाइस-बाउंड क्रिप्टोग्राफ़िक कीज़ को अधिकार के रूप में स्वीकार करती है जहाँ अद्वितीय डिवाइस बाइंडिंग मौजूद हो। यह ऑथेंटिकेशन के दौरान भुगतानकर्ता को जो दिखाया जाता है उसकी अखंडता पर भी जोर देती है। EBA Opinion 2019

PSD2 से पहले, कई बैंक SMS OTP या मुद्रित TAN सूचियों पर निर्भर थे, जो अक्सर अनुमोदन चरण के साथ राशि या प्राप्तकर्ता नहीं दिखाते थे। इस कमी ने एक बार क्रेडेंशियल चोरी हो जाने के बाद ग्राहकों को अनजाने ट्रांसफ़र को अधिकृत करने के लिए धोखा देना आसान बना दिया। डायनेमिक लिंकिंग को इस कमी को दूर करने के लिए पेश किया गया था, यह सुनिश्चित करके कि भुगतानकर्ता को ऑथेंटिकेशन के समय सटीक राशि और प्राप्तकर्ता के बारे में पता हो और ऑथेंटिकेशन कोड को उन विवरणों के लिए विशिष्ट बनाकर ताकि कोई भी बदलाव इसे अमान्य कर दे (RTS अनुच्छेद 5(1)(a–d))। जहाँ SMS प्रवाह का हिस्सा है, जारीकर्ताओं को ऑथेंटिकेशन के सभी चरणों में राशि/प्राप्तकर्ता और कोड की गोपनीयता, प्रामाणिकता और अखंडता भी सुनिश्चित करनी चाहिए (Q&A 2018_4414; RTS अनुच्छेद 5(2))। आज के इन-ऐप अनुमोदन (उदाहरण के लिए, "क्या आप फेस आईडी के माध्यम से जॉन स्मिथ को 100 USD अधिकृत करना चाहते हैं?") इस "जो आप देखते हैं वही आप साइन करते हैं" सिद्धांत को ग्राहक-अनुकूल तरीके से लागू करते हैं।

आज, मोबाइल पर, दो पैटर्न हावी हैं। पहला, एक पुश नोटिफ़िकेशन ग्राहक को ट्रांज़ैक्शन विवरण की समीक्षा करने और अनुमोदन करने के लिए ऐप में डीप-लिंक कर सकता है। पर्यवेक्षकों ने स्पष्ट किया है कि यदि अनुच्छेद 7 के नियंत्रण अनधिकृत उपयोग को कम करने और प्रतिकृति को रोकने के लिए मौजूद हैं, और समग्र यात्रा RTS का अनुपालन करती है, तो पुश अधिकार तत्व के प्रमाण के रूप में काम कर सकता है; फिर भी, सोशल-इंजीनियरिंग जोखिम बने रहते हैं और उन्हें UX में संबोधित किया जाना चाहिए (Q&A 2019_4984; RTS अनुच्छेद 7)।

दूसरा, डिवाइस के नेटिव बायोमेट्रिक्स (एक PIN फ़ॉलबैक के साथ) का उपयोग करके अनुमोदन स्थानीय रूप से यूज़र वेरिफिकेशन करते हैं ताकि एक प्राइवेट की ऑपरेशन को अनलॉक किया जा सके। प्राइवेट की एक सुरक्षित हार्डवेयर वातावरण (Secure Enclave/TEE/TPM) में रहती है और एक चैलेंज पर हस्ताक्षर करती है। यह SCA से स्पष्ट रूप से मेल खाता है: स्वामित्व (बायोमेट्रिक) और अधिकार जिसका प्रमाण डिवाइस बाइंडिंग और डिवाइस-बाउंड क्रिप्टोग्राफ़िक की से मिलता है (EBA‑Op‑2019‑06, पैरा. 25, 35–37)। रिमोट पेमेंट्स के लिए, कोड को गतिशील रूप से राशि और प्राप्तकर्ता से जोड़ा जाना चाहिए और उन विवरणों को यूज़र वेरिफिकेशन से पहले भुगतानकर्ता को दिखाया जाना चाहिए (RTS अनुच्छेद 5)। यदि दोनों कारक एक ही डिवाइस पर हैं, तो अलग-अलग सुरक्षित निष्पादन वातावरण और अखंडता जांच लागू करें ताकि एक का समझौता दूसरे को प्रभावित न करे (RTS अनुच्छेद 9(2)–(3))।

अंदर की बात यह है कि, स्थानीय बायोमेट्रिक्स सीधे "बैंक को ऑथेंटिकेट" नहीं करते हैं। इसके बजाय, बायोमेट्रिक (या PIN फ़ॉलबैक) डिवाइस पर यूज़र वेरिफिकेशन करता है और हार्डवेयर-समर्थित सुरक्षा मॉड्यूल में संग्रहीत एक गैर-निर्यात योग्य प्राइवेट की तक पहुंच को नियंत्रित करता है। जब भुगतानकर्ता मंज़ूरी देता है, तो डिवाइस उस प्राइवेट की का उपयोग बैंक द्वारा प्रदान किए गए चैलेंज पर एक डिजिटल सिग्नेचर बनाने के लिए करता है। यदि बैंक उस चैलेंज को ट्रांज़ैक्शन के एक कैनॉनिकल स्नैपशॉट (राशि, प्राप्तकर्ता, पहचानकर्ता) से प्राप्त या संबद्ध करता है, तो परिणामी सिग्नेचर एक ऑथेंटिकेशन कोड के रूप में कार्य करता है जो उन विवरणों के लिए विशिष्ट होता है। कोई भी बदलाव कोड को अमान्य कर देगा क्योंकि संग्रहीत स्नैपशॉट अब मेल नहीं खाता है, या, उन्नत डिज़ाइनों में, क्योंकि चैलेंज डेरिवेशन बदल जाता है। भुगतानकर्ता-जागरूकता वाला हिस्सा एक UX आवश्यकता बना रहता है: यूज़र वेरिफिकेशन से ठीक पहले बैंक-नियंत्रित दृश्य में राशि और प्राप्तकर्ता दिखाएं। साथ में, यह जागरूकता, विशिष्टता/अद्वितीयता और बदलाव पर अमान्यकरण पर RTS अनुच्छेद 5 की आवश्यकताओं को पूरा करता है, जबकि अनुच्छेद 7 के नियंत्रण और डिवाइस बाइंडिंग अधिकार तत्व का प्रमाण देते हैं।

• अधिकार (डिवाइस-बाउंड और सिंक की गई कीज़): पासकी प्राइवेट कीज़ सुरक्षित हार्डवेयर (TEE/Secure Enclave/TPM) में संग्रहीत होती हैं। डिवाइस-बाउंड पासकीज़ गैर-निर्यात योग्य होती हैं, जो अद्वितीय डिवाइस बाइंडिंग के लिए EBA की अपेक्षाओं के अनुरूप हैं (EBA‑Op‑2019‑06, पैरा. 25, 35–37)। सिंक की गई पासकीज़ भी प्रत्येक ऑथेंटिकेशन पर अधिकार का प्रमाण दे सकती हैं, बशर्ते डिवाइस बाइंडिंग और एंटी-रेप्लिकेशन नियंत्रण प्रभावी हों; नियामकों ने तत्व और डिवाइस के बीच एक विश्वसनीय लिंक की आवश्यकता पर जोर दिया है (EBA‑Op‑2019‑06; RTS अनुच्छेद 7)।
• स्वामित्व/ज्ञान (यूज़र वेरिफिकेशन): बायोमेट्रिक (स्वामित्व) या डिवाइस PIN (ज्ञान) के माध्यम से यूज़र वेरिफिकेशन स्थानीय रूप से की को सक्रिय करता है। अधिकार के साथ संयुक्त होने पर, यह कारक स्वतंत्रता के साथ सच्चा 2FA है। एक का उल्लंघन दूसरे से समझौता नहीं करता है।

डायनेमिक लिंकिंग ऑथेंटिकेशन को ट्रांज़ैक्शन से बाइंड करने के बारे में है। एक बैंक के लिए सवाल यह है: यदि हम एक यूज़र को पासकी के माध्यम से भुगतान को मंज़ूर करने देते हैं (उदाहरण के लिए, OTP या साइनिंग डिवाइस के बजाय), तो क्या हम गारंटी दे सकते हैं कि यह मंज़ूरी इच्छित राशि और प्राप्तकर्ता के लिए विशिष्ट है, और इसका पुन: उपयोग या हेरफेर नहीं किया जा सकता है?

पासकीज़ के साथ डायनेमिक लिंकिंग को लागू करने के 2 विकल्प हैं:

• सर्वर-साइड लिंकिंग (मानक): एक वन-टाइम WebAuthn चैलेंज जेनरेट करें जिसे बैकएंड सटीक राशि और प्राप्तकर्ता के साथ जोड़ता है। यूज़र बैंक-नियंत्रित व्यू में "€X से Y" देखता है और पासकी के साथ मंज़ूरी देता है। प्रतिक्रिया केवल उस ट्रांज़ैक्शन के लिए स्वीकार की जाती है। कोई भी बदलाव इसे अमान्य कर देता है।
• क्रिप्टोग्राफ़िक समावेशन (उन्नत): चैलेंज में राशि/प्राप्तकर्ता का हैश एम्बेड करें ताकि सिग्नेचर ट्रांज़ैक्शन डेटा के लिए प्रतिबद्ध हो। यह RTS द्वारा आवश्यक नहीं है लेकिन यह आश्वासन देता है कि बैकएंड स्वैप भी वेरिफिकेशन में विफल हो जाएंगे।

स्पष्ट अनुपालन नोट: RTS को यह आवश्यक नहीं है कि डायनेमिक-लिंकिंग "ऑथेंटिकेशन कोड" भुगतानकर्ता के डिवाइस पर कंप्यूट किया जाए। एक PSP इसे सर्वर पर जेनरेट और वैलिडेट कर सकता है जब तक कि राशि/प्राप्तकर्ता सुरक्षित हों और कोई भी बदलाव कोड को अमान्य कर दे (कोड के स्थान/समय पर EBA Q&A 2020_5366 देखें)। यह हमारा सर्वर-साइड डायनेमिक लिंकिंग (मानक) दृष्टिकोण है।

दोनों ट्रांज़ैक्शन के लिए एक अद्वितीय, गैर-पुन: प्रयोज्य "ऑथेंटिकेशन कोड" देते हैं। प्राथमिक चेतावनी Payer Awareness है: WebAuthn स्वयं यह साबित नहीं करता कि क्या प्रदर्शित किया गया था। डिस्प्ले की अखंडता बैंक-नियंत्रित UI से आनी चाहिए।

RTS अनुच्छेद 5 की आवश्यकता है कि भुगतानकर्ता ऑथेंटिकेशन के दौरान राशि और प्राप्तकर्ता को देखे। WebAuthn यह प्रमाणित नहीं करता कि क्या दिखाया गया था। सिद्धांत रूप में, यदि ऐप या OS से छेड़छाड़ की जाती है, तो एक यूज़र को गुमराह किया जा सकता है जबकि ऑथेंटिकेटर अभी भी साइन करता है। हम नीचे विस्तार से विश्लेषण करेंगे कि यह जोखिम वास्तविकता में कैसे काम करता है और यह एक वास्तविक सुरक्षा जोखिम क्यों नहीं है और विनियमन की व्याख्या का मुद्दा अधिक है।

डिस्प्ले-अखंडता नियंत्रण जिन्हें हम लागू करते हैं:

• बैंक-नियंत्रित व्यू राशि + प्राप्तकर्ता को रेंडर करता है: यदि व्यू अस्पष्ट या फ़ोकस से बाहर है तो हम पासकी आह्वान को ब्लॉक करते हैं
• ऐप/वेब में ओवरले/छेड़छाड़ का पता लगाना: छिपे हुए iframes से कोई पासकी प्रॉम्प्ट नहीं
• डिवाइस अखंडता/अटेस्टेशन गेटिंग: रूটেড/जेलब्रोकन/समझौता किए गए सिग्नलों पर अस्वीकार या स्टेप-अप करें
• राशि/प्राप्तकर्ता के सर्वर-हेल्ड स्नैपशॉट के खिलाफ एटॉमिक मंज़ूरी: किसी भी पैरामीटर परिवर्तन पर एक नए चैलेंज की आवश्यकता होती है

क्रिप्टोग्राफ़िक समावेशन के बारे में: WebAuthn "ट्रांज़ैक्शन डिस्प्ले" एक्सटेंशन (SPC) आज व्यापक रूप से समर्थित नहीं हैं। हमारा पोर्टेबल बेसलाइन सर्वर-साइड बाइंडिंग है, जिसे ट्रांज़ैक्शन स्नैपशॉट से चैलेंज प्राप्त करके प्रबलित किया जाता है (जैसे, H(राशि ‖ प्राप्तकर्ता ‖ txnId ‖ नॉन्स)) ताकि सिग्नेचर उन मानों के लिए प्रतिबद्ध हो।

दोनों पैटर्न गैर-निर्यात योग्य डिवाइस कीज़ के साथ पब्लिक-की क्रिप्टोग्राफ़ी का उपयोग करते हैं, और दोनों साइनिंग ऑपरेशन को अनलॉक करने के लिए स्थानीय यूज़र वेरिफिकेशन पर निर्भर करते हैं। दोनों में, बैंक यूज़र वेरिफिकेशन से ठीक पहले बैंक-नियंत्रित व्यू में राशि और प्राप्तकर्ता दिखाकर Payer Awareness सुनिश्चित करता है, और ऑथेंटिकेशन कोड को उन विवरणों से बाइंड करके विशिष्टता सुनिश्चित करता है - किसी भी बदलाव पर इसे अमान्य करता है (RTS अनुच्छेद 5(1)(a–d))। RTS प्रौद्योगिकी-तटस्थ है और यह आवश्यक नहीं है कि राशि/प्राप्तकर्ता को OS बायोमेट्रिक मोडल के अंदर रेंडर किया जाए; यह भुगतानकर्ता को प्रदर्शन और कोड की बाइंडिंग की आवश्यकता है (RTS अनुच्छेद 5)। जब दोनों SCA तत्व एक डिवाइस पर निष्पादित होते हैं, तो अनुच्छेद 9 की अखंडता और अलगाव की आवश्यकताएं समान रूप से लागू होती हैं (RTS अनुच्छेद 9(2)–(3))। अंत में, डायनेमिक-लिंकिंग गणना का स्थान लचीला है: इसे सर्वर-साइड पर किया जा सकता है यदि अखंडता संरक्षित है और कोई भी बदलाव कोड को अमान्य कर देता है (Q&A 2020_5366)। ये वही शर्तें हैं जिनके तहत नियामक पहले से ही PKI के साथ स्थानीय बायोमेट्रिक्स को स्वीकार करते हैं - इसलिए, पासकीज़, समान Payer Awareness और बाइंडिंग नियंत्रणों के साथ लागू किए गए, एक समान आधार पर स्वीकार किए जाने चाहिए।

तो, क्या WebAuthn मानक के अनुसार सादे पासकीज़ डायनेमिक लिंकिंग के इरादे को पूरा करते हैं? आंशिक रूप से:

• MITM/नेटवर्क हमले: हाँ। ऑरिजिन बाइंडिंग और प्रति-चैलेंज सिग्नेचर छेड़छाड़ और रीप्ले को रोकते हैं।
• ट्रांज़ैक्शन अखंडता: हाँ। सर्वर एसोसिएशन या चैलेंज-हैशिंग यह सुनिश्चित करता है कि केवल मूल राशि/प्राप्तकर्ता ही वेरिफ़ाई होगा।
• भुगतानकर्ता की सहमति: कठिन। पासकीज़ में ऑथेंटिकेटर-स्तर के डिस्प्ले की कमी होती है। समझौता किए गए उपकरणों पर UI धोखे की संभावना हो सकती है। भुगतानकर्ता की सहमति की गारंटी के लिए इसके ऊपर कुछ बनाना होगा।

पासकीज़ के साथ डायनेमिक लिंकिंग की अभी भी आवश्यकता क्यों है

• कानूनी: PSD2 अनुच्छेद 97(2) और RTS अनुच्छेद 5 सभी रिमोट पेमेंट इनीशिएशन के लिए डायनेमिक लिंकिंग को अनिवार्य करते हैं। फ़िशिंग-प्रतिरोधी तरीकों के लिए कोई छूट नहीं है।
• सुरक्षा: पासकीज़ क्रॉस-ऑरिजिन फ़िशिंग को हटाते हैं, लेकिन वे स्वयं यह सबूत नहीं देते कि भुगतानकर्ता को क्या दिखाया गया था। डायनेमिक लिंकिंग + डिस्प्ले-अखंडता नियंत्रण यह सुनिश्चित करते हैं कि विशिष्ट राशि/प्राप्तकर्ता जो यूज़र ने देखा था, वही बैंक निष्पादित करता है, और कोई भी बदलाव मंज़ूरी को अमान्य कर देता है।

संक्षेप में, पासकीज़ डायनेमिक लिंकिंग को संतुष्ट कर सकते हैं जब उन्हें ट्रांज़ैक्शन डेटा से सख्ती से बाइंड किया जाता है और भरोसेमंद डिस्प्ले तंत्र के साथ जोड़ा जाता है। अवशिष्ट चुनौती यह साबित करना है कि यूज़र ने वास्तव में क्या देखा।

कॉर्बाडो एक डायनेमिक लिंकिंग अनुपालक समाधान प्रदान करता है जो ऊपर उल्लिखित भुगतानकर्ता-सहमति विचारों को स्पष्ट रूप से संबोधित करता है।

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

प्रक्रिया प्रवाह:

• बैंक-नियंत्रित डिस्प्ले भुगतानकर्ता को सटीक राशि और प्राप्तकर्ता दिखाता है। जब तक यह व्यू दिखाई न दे, कोई पासकी प्रॉम्प्ट नहीं दिखाया जाता है।
• ऑथेंटिकेशन: क्लाइंट कैनॉनिकलाइज़्ड ट्रांज़ैक्शन के लिए एक वन-टाइम, बाउंड चैलेंज के साथ WebAuthn को इनवोक करता है। ऑथेंटिकेटर यूज़र वेरिफिकेशन (बायोमेट्रिक या डिवाइस PIN) करता है और चैलेंज और ऑरिजिन पर साइन करता है।
• सर्वर वेरिफिकेशन: बैकएंड RP ID हैश और ऑरिजिन को वेरिफ़ाई करता है, चैलेंज को संग्रहीत ट्रांज़ैक्शन से मिलाता है, UV/फ्लैग की जांच करता है, वन-टाइम उपयोग और समाप्ति लागू करता है, और संग्रहीत राशि/प्राप्तकर्ता स्नैपशॉट की तुलना करता है।
• मंज़ूरी और ऑडिट: केवल तभी ट्रांज़ैक्शन को एटॉमिक रूप से मंज़ूर किया जाता है। किसी भी बेमेल/बदलाव को अस्वीकार कर दिया जाता है और एक नए ऑथेंटिकेशन की आवश्यकता होती है। एक अपरिवर्तनीय ऑडिट रिकॉर्ड बना रहता है (क्रेडेंशियल ID, ऑथेंटिकेटरडेटा, क्लाइंटडेटाJSON, सिग्नेचर, चैलेंज, और कैनॉनिकलाइज़्ड राशि/प्राप्तकर्ता), वैकल्पिक रूप से छेड़छाड़ के सबूत के लिए हैश-चेन किया जाता है।
• डिवाइस अखंडता गेट: डिवाइस की अखंडता और अटेस्टेशन संकेतों का मूल्यांकन करें: यदि डिवाइस रूটেড/जेलब्रोकन/समझौता किया हुआ है तो अस्वीकार करें या स्टेप-अप करें।
• प्राप्तकर्ता कैनॉनिकलाइज़ेशन: एक अनुकूल लेबल प्रदर्शित करें (जैसे, "ACME GmbH"), लेकिन एक कैनॉनिकल प्राप्तकर्ता पहचानकर्ता (जैसे, IBAN/BIC या अन्य अद्वितीय योजना) के खिलाफ बाइंड और वेरिफ़ाई करें।

तकनीकी विवरण:

• बैकएंड: कैनॉनिकलाइज़्ड डेटा के साथ एक ट्रांज़ैक्शन ऑब्जेक्ट बनाएं (जैसे, सामान्यीकृत मुद्रा/दशमलव; कैनॉनिकलाइज़्ड IBAN/लाभार्थी)। इन मानों के लिए प्रतिबद्ध एक अल्पकालिक चैलेंज जेनरेट करें (जैसे, H(राशि||प्राप्तकर्ता||txnId||नॉन्स)); लंबित स्टोर करें; क्लाइंट को केवल अपारदर्शी ID ही दिखाएं।
• क्लाइंट/ऑथेंटिकेटर: भुगतानकर्ता के विवरण को बैंक-नियंत्रित व्यू में रेंडर करें; केवल दिखाई देने पर WebAuthn (RP ID = Bison डोमेन) को इनवोक करें; यूज़र वेरिफिकेशन की आवश्यकता है; ऑथेंटिकेटर WebAuthn के अनुसार चैलेंज + ऑरिजिन पर साइन करता है।
• वेरिफिकेशन/अंतिम रूप देना: सिग्नेचर, RP ID हैश, ऑरिजिन/प्रकार, UV फ्लैग को वैलिडेट करें; एंटी-रीप्ले/समाप्ति; अपरिवर्तनीय राशि/प्राप्तकर्ता स्नैपशॉट की तुलना करें; एटॉमिक रूप से मंज़ूर करें; ऑडिट रिकॉर्ड को बनाए रखें।
• स्नैपशॉट से चैलेंज प्राप्त करें: challenge = H(राशि ‖ कैनॉनिकलप्राप्तकर्ता ‖ txnId ‖ नॉन्स)

UX नीतियां:

• राशि/प्राप्तकर्ता पर स्पष्ट जोर; सुलभ पुष्टि/रद्द नियंत्रण; छोटे टाइमआउट; हमेशा एक नए चैलेंज का उपयोग करके ग्रेसफुल रिट्राइज़; तत्काल रसीदें (जैसे, "आपने Y को €X मंज़ूर किया है")। यदि डिस्प्ले अस्पष्ट है तो पासकी प्रॉम्प्ट को ब्लॉक करें और यदि साइन करने से पहले पैरामीटर बदलते हैं तो चेतावनी दें।
• ओवरले/अस्पष्ट सामग्री का पता लगाएं: यदि ट्रांज़ैक्शन व्यू दिखाई नहीं दे रहा है तो कभी भी पासकी प्रॉम्प्ट न दिखाएं। यदि प्रवाह के बीच में पैरामीटर बदलते हैं तो अस्वीकार करें और एक नए चैलेंज के साथ पुनरारंभ करें।

अनुपालन नोट: यह एंड-टू-एंड डिज़ाइन RTS अनुच्छेद 5 को पूरा करता है: Payer Awareness (बैंक-नियंत्रित डिस्प्ले), विशिष्टता और अद्वितीयता (राशि/प्राप्तकर्ता से बाउंड वन-टाइम कोड), बदलाव पर अमान्यकरण (सख्त सर्वर जांच), और सभी चरणों में राशि/प्राप्तकर्ता और कोड की गोपनीयता/अखंडता (RTS अनुच्छेद 5(1)(a–d), 5(2); SMS अखंडता के लिए Q&A 2018_4414 भी देखें)। कारक स्वतंत्रता (अनुच्छेद 7-9) को डिवाइस-बाउंड अधिकार और उपयुक्त सुरक्षा के साथ बहु-उद्देश्यीय उपकरणों पर स्थानीय यूज़र वेरिफिकेशन के माध्यम से संरक्षित किया जाता है (RTS अनुच्छेद 9(2)–(3))।

नोट: * वेब प्रवाह के लिए, कॉर्बाडो वैकल्पिक रूप से [Secure Payment Confirmation](https://www.w3.org/TR/payment-request-secure-payment-confirmation/) को अपनाएगा यदि/जब Apple व्यापक समर्थन प्रदान करता है, एक विश्वसनीय ब्राउज़र-मध्यस्थ डिस्प्ले जोड़ता है जो क्रिप्टोग्राफ़िक रूप से राशि और प्राप्तकर्ता को प्रमाणित करता है।

चिंता: फ़िशिंग हमले प्रतिक्रिया: पासकीज़ डिज़ाइन द्वारा फ़िशिंग-प्रतिरोधी हैं: वे वैध ऑरिजिन से बंधे हैं और इसमें कोई साझा रहस्य शामिल नहीं है, इसलिए नकली साइट पर क्रेडेंशियल एकत्र नहीं किए जा सकते, OTP के विपरीत। एक हमलावर जो ट्रैफ़िक को एक समान दिखने वाले डोमेन पर प्रॉक्सी करता है, बैंक के ऑरिजिन के लिए एक मान्य सिग्नेचर प्राप्त नहीं कर सकता है। डायनेमिक लिंकिंग इस वेक्टर में कम योगदान देती है, लेकिन यह सुनिश्चित करने के लिए अनिवार्य बनी हुई है कि कोई भी मंज़ूरी इच्छित राशि और प्राप्तकर्ता के लिए अद्वितीय हो। पूरक उपाय (फ़िशिंग शिक्षा, लॉगिन बनाम पेमेंट मंज़ूरी का स्पष्ट अलगाव, असामान्य पेमेंट संदर्भों के लिए विसंगति/जोखिम स्कोरिंग) जोखिम को और कम करते हैं।

चिंता: सोशल इंजीनियरिंग / ऑथराइज़्ड पुश पेमेंट (APP) धोखाधड़ी प्रतिक्रिया: कोई भी ऑथेंटिकेटर यूज़र को झूठे बहाने (जैसे, "सुरक्षित खाता" घोटाले) के तहत भुगतान अधिकृत करने से पूरी तरह नहीं रोक सकता है। डायनेमिक लिंकिंग यह सुनिश्चित करती है कि यूज़र स्पष्ट रूप से प्राप्तकर्ता और राशि देखता है और सहमति का मजबूत सबूत प्रदान करता है, लेकिन यह एक आश्वस्त भुगतानकर्ता को ओवरराइड नहीं कर सकता है। क्षतिपूर्ति में प्रासंगिक चेतावनियाँ (नया प्राप्तकर्ता, पहला बड़ा ट्रांसफ़र), उच्च जोखिम वाले प्राप्तकर्ताओं के लिए कूलिंग-ऑफ़ अवधि या विलंबित निष्पादन, मजबूत प्राप्तकर्ता वेरिफिकेशन, और जोखिम संकेतों पर स्टेप-अप जांच (अतिरिक्त पुष्टि) शामिल हैं। भुगतान के बाद की सूचनाएं और त्वरित विवाद चैनल नुकसान का पता लगाने और उसे रोकने में मदद करते हैं। हम वास्तविक समय में प्रासंगिक चेतावनियाँ (जैसे, नया प्राप्तकर्ता, पहला बड़ा ट्रांसफ़र), उच्च जोखिम वाले प्राप्तकर्ताओं के लिए कूलिंग-ऑफ़ अवधि, मजबूत प्राप्तकर्ता वेरिफिकेशन और भुगतान के बाद की सूचनाएं ("आपने Y को €X मंज़ूर किया है") जोड़ते हैं ताकि पता लगाने और प्रतिक्रिया में तेज़ी लाई जा सके।

चिंता: मैलवेयर या डिवाइस से समझौता प्रतिक्रिया: प्राइवेट कीज़ गैर-निर्यात योग्य हैं और प्रत्येक सिग्नेचर के लिए स्थानीय यूज़र वेरिफिकेशन की आवश्यकता होती है, इसलिए मैलवेयर केवल क्रेडेंशियल नहीं निकाल सकता है। यथार्थवादी जोखिम पूरी तरह से समझौता किए गए OS पर UI धोखा है। सुरक्षित/सत्यापित UI (जैसे, संरक्षित पुष्टिकरण), डिवाइस अखंडता जांच/अटेस्टेशन और उच्च जोखिम वाले उपकरणों को ब्लॉक करने, और उपलब्ध होने पर SPC या पुष्टिकरण एक्सटेंशन जैसे विश्वसनीय पुष्टिकरणों के साथ शमन करें। यदि समझौते के संकेतक दिखाई देते हैं (ओवरले डिटेक्शन, रूट/जेलब्रेक), तो आउट-ऑफ़-बैंड पुन: वेरिफिकेशन का उपयोग करें या निष्पादन से इनकार करें। पूरी तरह से स्वामित्व वाले डिवाइस पर कोई भी उपभोक्ता विधि सही नहीं है, लेकिन ये नियंत्रण नाटकीय रूप से खिड़की को संकीर्ण करते हैं।

चिंता: मैन-इन-द-ब्राउज़र / सत्र अपहरण प्रतिक्रिया: दुर्भावनापूर्ण एक्सटेंशन या इंजेक्ट किए गए स्क्रिप्ट वैध ऑरिजिन पर कार्रवाई शुरू कर सकते हैं। ऑरिजिन-बाउंड पासकीज़ क्रॉस-साइट फ़िशिंग को रोकते हैं। डायनेमिक लिंकिंग यह सुनिश्चित करती है कि राशि/प्राप्तकर्ता में पर्दे के पीछे के संपादन विफल हों। हम CSP/एंटी-टैम्पर नियंत्रणों के माध्यम से चैनल को कठोर करते हैं और प्रत्येक पुष्टि के लिए एक ताज़ा, वन-टाइम चैलेंज की आवश्यकता होती है।

चिंता: अंदरूनी खतरा या सर्वर-साइड छेड़छाड़ प्रतिक्रिया: ऑथेंटिकेशन प्रतिक्रिया विशिष्ट रूप से मूल राशि/प्राप्तकर्ता से जुड़ी होती है, इसलिए कोई भी सर्वर-साइड प्रतिस्थापन वैलिडेशन में विफल रहता है। ऑडिट/गैर-अस्वीकरण के लिए छेड़छाड़-स्पष्ट, अपरिवर्तनीय लिंकेज रिकॉर्ड (चैलेंज, क्रेडेंशियल, सिग्नेचर, और कैनॉनिकलाइज़्ड राशि/प्राप्तकर्ता) बनाए रखें। अंदरूनी जोखिम को कम करने के लिए महत्वपूर्ण पेमेंट प्रोसेसिंग पथों पर कर्तव्यों का पृथक्करण और चार-आंखों के नियंत्रण लागू करें।

चिंता: चोरी हुए डिवाइस / क्रेडेंशियल चोरी प्रतिक्रिया: केवल डिवाइस का अधिकार अपर्याप्त है: प्रत्येक सिग्नेचर के लिए यूज़र वेरिफिकेशन (बायोमेट्रिक/PIN) आवश्यक है, जिसमें OS-स्तर की दर सीमाएं और तालाबंदी होती है। प्रत्येक भुगतान के लिए एक ताज़ा, ट्रांज़ैक्शन-विशिष्ट चैलेंज की आवश्यकता होती है; सामान्य सत्र टोकन मनमाने भुगतानों को अधिकृत नहीं कर सकते हैं। रिमोट डिवाइस निरस्तीकरण, नए डिवाइस के उपयोग पर स्टेप-अप, जियोवेलोसिटी जांच, और सूचनाएं ("आपने Y को €X अधिकृत किया है") जैसे अतिरिक्त उपाय दुरुपयोग को और सीमित करते हैं।

कुल मिलाकर: पासकीज़ फ़िशिंग और रीप्ले जोखिमों को भौतिक रूप से कम करते हैं; ट्रांज़ैक्शन की अखंडता की गारंटी देने, मंज़ूरी को राशि/प्राप्तकर्ता से बाइंड करने और शेष खतरे के परिदृश्यों में सूचित सहमति का मजबूत सबूत प्रदान करने के लिए डायनेमिक लिंकिंग आवश्यक बनी हुई है।

प्रश्न 1: हम कैसे साबित कर सकते हैं कि यूज़र ने पासकी का उपयोग करते समय वास्तव में राशि और प्राप्तकर्ता को देखा और उससे सहमत हुआ? प्रतिक्रिया: हम बैंक-नियंत्रित व्यू में भुगतानकर्ता डिस्प्ले लागू करते हैं और मंज़ूरी को राशि/प्राप्तकर्ता के सर्वर-साइड स्नैपशॉट से जोड़ते हैं। पासकी असर्शन (ऑथेंटिकेटरडेटा, क्लाइंटडेटाJSON, सिग्नेचर) केवल उस स्नैपशॉट से प्राप्त चैलेंज के लिए स्वीकार किया जाता है; किसी भी बदलाव के लिए एक नए चैलेंज की आवश्यकता होती है। हमारा छेड़छाड़-स्पष्ट ऑडिट असर्शन को "€X से प्राप्तकर्ता-ID Y" से जोड़ता है और रिकॉर्ड करता है कि यदि विवरण भिन्न होते तो हमारा सिस्टम आगे नहीं बढ़ता। जहां समर्थित है, SPC क्रिप्टोग्राफ़िक सबूत जोड़ता है कि यूज़र ने प्रदर्शित विवरणों की पुष्टि की।

प्रश्न 1: हम कैसे साबित कर सकते हैं कि यूज़र ने पासकी का उपयोग करते समय वास्तव में राशि और प्राप्तकर्ता को देखा और उससे सहमत हुआ? प्रतिक्रिया: यह अनिवार्य रूप से गैर-अस्वीकरण का प्रश्न है। PSD2 के तहत, डायनेमिक लिंकिंग का उद्देश्य यह सुनिश्चित करना था कि यूज़र इस बात से अवगत हो कि वे क्या मंज़ूर कर रहे हैं। पासकी के साथ, जो सबूत हम बनाए रखते हैं वह क्रिप्टोग्राफ़िक सिग्नेचर (ऑथेंटिकेशन कोड) और संबंधित डेटा (यह हमारे सर्वर पर किस राशि/प्राप्तकर्ता से बंधा था) है। नीति के अनुसार, हम ऑथेंटिकेट करने से पहले ऐप या वेब पेज में यूज़र को ट्रांज़ैक्शन विवरण दिखाते हैं। हम उस स्क्रीन/व्यू और उस विशिष्ट ट्रांज़ैक्शन के लिए बाद में सफल पासकी ऑथेंटिकेशन को लॉग करते हैं। विवाद के मामले में, हम दिखा सकते हैं कि यूज़र के डिवाइस ने एक चैलेंज के लिए एक मान्य सिग्नेचर बनाया जो (उदाहरण के लिए) "€100 से ACME Corp." से जुड़ा था और यदि कोई विवरण अलग होता तो हमारा सिस्टम आगे नहीं बढ़ता। हमारा अनुपालन सुरक्षित लॉगिंग पर निर्भर करता है: हम यह सुनिश्चित करते हैं कि हमारे सिस्टम पासकी प्रतिक्रिया को ट्रांज़ैक्शन डेटा से जोड़ने में छेड़छाड़-प्रूफ हैं।

प्रश्न 2: क्या होगा यदि डिवाइस या OS से छेड़छाड़ की जाती है? क्या मैलवेयर ट्रांज़ैक्शन या पासकी प्रक्रिया में हेरफेर कर सकता है? प्रतिक्रिया: किसी भी डिजिटल बैंकिंग परिदृश्य में डिवाइस से समझौता एक महत्वपूर्ण खतरा है। यदि ऑपरेटिंग सिस्टम दुर्भावनापूर्ण है, तो यह यूज़र को गुमराह करने या प्रक्रियाओं को हाइजैक करने का प्रयास कर सकता है। हालांकि, इस सबसे बुरे मामले में भी, पासकीज़ कुछ प्रमुख सुरक्षा बनाए रखते हैं। प्राइवेट की को मैलवेयर द्वारा नहीं निकाला जा सकता है। मैलवेयर यूज़र का बैंक के सामने प्रतिरूपण भी नहीं कर सकता है, क्योंकि यह यूज़र के बायोमेट्रिक/PIN के बिना पासकी सिग्नेचर नहीं बना सकता है। यह सबसे अधिक यूज़र को झूठे बहाने से कुछ ऑथेंटिकेट करने के लिए प्रेरित कर सकता है। डायनेमिक लिंकिंग यहां अखंडता जांच की आवश्यकता करके मदद करती है: मैलवेयर बाद में ट्रांज़ैक्शन विवरण को चुपचाप नहीं बदल सकता है - यदि ऐसा होता है, तो सिग्नेचर वेरिफ़ाई नहीं होगा। सबसे कमजोर बिंदु डिस्प्ले/UI है: एक परिष्कृत ट्रोजन यूज़र को जो दिखता है उसे बदल सकता है (उदाहरण के लिए, "ACME Corp" प्रदर्शित करें जबकि अंतर्निहित ट्रांज़ैक्शन वास्तव में दूसरे प्राप्तकर्ता को जा रहा है)। यह तुच्छ नहीं है, खासकर यदि बैंक ऐप सुरक्षित UI फ्रेमवर्क का उपयोग करता है, लेकिन यह बोधगम्य है। यह सब कहने के बाद, यदि हम डिवाइस से छेड़छाड़ के संकेत (असामान्य व्यवहार, ज्ञात मैलवेयर सिग्नेचर, आदि) का पता लगाते हैं, तो हम आउट-ऑफ़-बैंड वेरिफिकेशन पर वापस आ जाएंगे या ट्रांज़ैक्शन से इनकार कर देंगे। संक्षेप में: यदि यूज़र का डिवाइस पूरी तरह से एक हमलावर के स्वामित्व में है तो कोई भी समाधान 100% नहीं है। पासकीज़ + डायनेमिक लिंकिंग हमले की सतह को नाटकीय रूप से कम करते हैं (एक हमलावर केवल क्रेडेंशियल प्रॉक्सी नहीं कर सकता है या नेटवर्क डेटा को बदल नहीं सकता है; उन्हें वास्तविक समय में यूज़र पर एक धोखा चलाना होगा)। यदि OS से छेड़छाड़ की जाती है, तो डायनेमिक लिंकिंग कम से कम यह सुनिश्चित करती है कि जो होना चाहिए और जो मंज़ूर किया गया है, उसके बीच किसी भी बेमेल को हमारे बैकएंड द्वारा पकड़ा जाता है।

प्रश्न 3: यदि पासकी को अनलॉक करने के लिए बायोमेट्रिक का उपयोग किया जाता है, तो क्या इसे एक कारक या दो माना जाता है? क्या हम 2-कारक नियम का अनुपालन कर रहे हैं? प्रतिक्रिया: एक बायोमेट्रिक अकेले SCA के लिए पर्याप्त नहीं है - यह सिर्फ एक स्वामित्व कारक है। हालांकि, एक पासकी कार्यान्वयन में बायोमेट्रिक अकेला नहीं है: डिवाइस का अधिकार दूसरा कारक है। यूज़र का बायोमेट्रिक डिवाइस पर संग्रहीत प्राइवेट की को अनलॉक करता है। अधिकार और स्वामित्व दो अलग-अलग श्रेणियां हैं। यह इस बात के समान है कि कई बैंकिंग ऐप पहले से ही SCA को कैसे संतुष्ट करते हैं: आपके पास फोन (अधिकार) है और आप ऐप को अनलॉक करने के लिए अपनी फिंगरप्रिंट या चेहरे का उपयोग करते हैं (स्वामित्व)। EBA ने डिवाइस-बाइंडिंग प्लस बायोमेट्रिक के संयोजन को स्पष्ट रूप से अनुपालक SCA के रूप में मान्यता दी है। पासकी परिदृश्य ठीक वही संयोजन है। यदि यूज़र पासकी को अनलॉक करने के लिए बायोमेट्रिक के बजाय PIN का उपयोग करने का विकल्प चुनता है, तो यह अधिकार + ज्ञान है, जो भी अनुपालक है। हम सभी पासकी ऑपरेशनों पर यूज़र वेरिफिकेशन लागू करते हैं (जिसका अर्थ है कि यूज़र को हर बार बायोमेट्रिक/PIN प्रदान करना होगा), इसलिए ऐसी कोई स्थिति नहीं है जहां सिर्फ डिवाइस का होना पर्याप्त हो। इस प्रकार, पासकी के माध्यम से प्रत्येक पेमेंट ऑथराइज़ेशन PSD2 परिभाषाओं के तहत एक दो-कारक घटना है।

प्रश्न 4: क्या एक हमलावर पासकी ऑथेंटिकेशन का पुन: उपयोग कर सकता है या ट्रांज़िट में डेटा में हेरफेर करके डायनेमिक लिंकिंग को बायपास कर सकता है? प्रतिक्रिया: नहीं। यहीं पर पासकीज़ और डायनेमिक लिंकिंग मजबूती से एक साथ काम करते हैं। प्रत्येक WebAuthn ऑथेंटिकेशन एक अद्वितीय सिग्नेचर देता है जो चैलेंज (जिसे हम प्रति ट्रांज़ैक्शन जेनरेट करते हैं) से बंधा होता है और हमारे डोमेन के लिए स्कोप किया जाता है। एक हमलावर उस सिग्नेचर को एक अलग ट्रांज़ैक्शन के लिए रीप्ले नहीं कर सकता है। सिग्नेचर स्वयं चैलेंज नॉन्स को शामिल करता है और केवल उसी चीज़ के लिए मान्य है जिसके लिए इसे मूल रूप से जारी किया गया था। यदि कोई हमलावर नेटवर्क संचार को इंटरसेप्ट करता है, तो वे सिग्नेचर को अमान्य किए बिना राशि या प्राप्तकर्ता को नहीं बदल सकते (क्योंकि चैलेंज या ट्रांज़ैक्शन संदर्भ अब मेल नहीं खाएगा)। यह प्रभावी रूप से MITM सुरक्षा है जिस पर हमने चर्चा की। इसके अलावा, पासकी सिग्नेचर में ऑरिजिन डेटा शामिल होता है - यदि वे हमारी सटीक वेबसाइट/ऐप ऑरिजिन पर नहीं भेजे जाते हैं तो वे वेरिफ़ाई नहीं होंगे, इसलिए फ़िशिंग या रीडायरेक्टिंग काम नहीं करेगा। संक्षेप में, कोई भी हेरफेर का प्रयास डायनेमिक लिंकिंग नियमों के अनुसार ऑथेंटिकेशन कोड को अमान्य कर देता है। यह वास्तव में कुछ मौजूदा OTP-आधारित प्रवाहों की तुलना में अधिक सुरक्षित है, जहां यूज़र कभी-कभी एक सामान्य कोड को मंज़ूर करते हैं और यह जोखिम होता है कि अनुरोध के साथ छेड़छाड़ की गई थी। पासकीज़ के साथ, हम क्रिप्टोग्राफ़िक रूप से यूज़र ऑथेंटिकेशन को विशिष्ट सत्र/ट्रांज़ैक्शन से बाइंड करते हैं।

प्रश्न 5: क्या SCA के लिए WebAuthn/पासकीज़ पर कोई ज्ञात नियामक राय है? क्या हम निश्चित हैं कि नियामक पासकीज़ को अनुपालक के रूप में स्वीकार करेंगे? प्रतिक्रिया: अभी तक, EBA ने अपने Q&A या मार्गदर्शन में WebAuthn या "पासकीज़" शब्द पर स्पष्ट रूप से कोई राय प्रकाशित नहीं की है। हालाँकि, उनके द्वारा निर्धारित सिद्धांतों के आधार पर, पासकीज़ स्पष्ट रूप से स्वीकार्य तरीकों के भीतर फिट होते हैं। EBA की 2019 की राय ने अनिवार्य रूप से FIDO2-जैसे दृष्टिकोणों का अनुमान लगाया: अधिकार के लिए, उन्होंने स्पष्ट रूप से अधिकार के प्रमाण के रूप में उचित डिवाइस बाइंडिंग के साथ "पब्लिक/प्राइवेट कीज़ का आदान-प्रदान" का उल्लेख किया है। एक WebAuthn पासकी ठीक वही है - एक पब्लिक/प्राइवेट की जोड़ी, जिसका प्राइवेट आधा हिस्सा डिवाइस से सुरक्षित रूप से बंधा होता है। उन्होंने एक मान्य अधिकार प्रमाण के रूप में "डिवाइस द्वारा जेनरेट किए गए सिग्नेचर" को भी मंजूरी दी। इसलिए जब उन्होंने पासकी शब्द का उपयोग नहीं किया, तो विधि उनके उदाहरणों द्वारा कवर की गई है। हमने यह भी देखा है कि यूरोप में प्रमुख पेमेंट खिलाड़ी पासकी कार्यान्वयन के साथ आगे बढ़ रहे हैं (जैसे PayPal) जो इस विश्वास के स्तर को इंगित करता है कि यह PSD2-अनुपालक है। यह उदाहरण दर्शाता है कि पासकीज़ को अनुपालक SCA प्रवाह के हिस्से के रूप में स्वीकार किया जा रहा है, बशर्ते डायनेमिक लिंकिंग और समग्र आवश्यकताएं पूरी हों।

प्रश्न 6: यदि पासकीज़ फ़िशिंग-प्रतिरोधी हैं तो क्या हमें अभी भी डायनेमिक लिंकिंग की आवश्यकता है? प्रतिक्रिया: हाँ। पासकीज़ क्रॉस-ऑरिजिन फ़िशिंग को खत्म करते हैं, लेकिन PSD2 अभी भी रिमोट पेमेंट इनीशिएशन के लिए डायनेमिक लिंकिंग को अनिवार्य करता है। डायनेमिक लिंकिंग विशिष्ट राशि और प्राप्तकर्ता को SCA परिणाम से बाइंड करती है और किसी भी बदलाव को अमान्य करती है, फ़िशिंग से परे ऑथराइज़ेशन अखंडता को संबोधित करती है (जैसे, MITM/MITB/TPP प्रतिस्थापन)।

कॉर्बाडो का समाधान डायनेमिक लिंकिंग और PSD2-अनुपालक है। प्री-ऑथ भुगतानकर्ता डिस्प्ले, राशि और प्राप्तकर्ता से बंधा वन-टाइम चैलेंज, सख्त सर्वर वेरिफिकेशन, और अपरिवर्तनीय ऑडिट एक साथ Payer Awareness, अद्वितीयता/विशिष्टता, बदलाव पर अमान्यकरण, और अखंडता/गोपनीयता पर RTS अनुच्छेद 5 की आवश्यकताओं को पूरा करते हैं। कारक स्वतंत्रता को डिवाइस-बाउंड अधिकार और UV (बायोमेट्रिक या PIN) के माध्यम से संरक्षित किया जाता है, जो EBA मार्गदर्शन के अनुरूप है।

आज के OTP/SMS तरीकों की तुलना में, कॉर्बाडो भौतिक रूप से बेहतर सुरक्षा और यूज़र परिणाम प्रदान करता है: फ़िशिंग और रिले का प्रतिरोध, साइलेंट पैरामीटर छेड़छाड़ की रोकथाम, मजबूत गैर-अस्वीकार्य सबूत, और ऑन-डिवाइस UV के माध्यम से कम घर्षण। अवशिष्ट जोखिम (जैसे, सोशल इंजीनियरिंग, समझौता किए गए डिवाइस) को ठोस नियंत्रणों के साथ कम किया जाता है और वे विरासत तरीकों की तुलना में संकीर्ण होते हैं। वेब के लिए, कॉर्बाडो SPC को अपना सकता है जब प्लेटफ़ॉर्म समर्थन (विशेष रूप से Apple) व्यापक हो, मुख्य अनुपालन मुद्रा को बदले बिना डिस्प्ले का क्रिप्टोग्राफ़िक प्रमाण जोड़ता है।

संक्षेप में, कॉर्बाडो का पासकी-आधारित ट्रांज़ैक्शन ऑथराइज़ेशन PSD2 डायनेमिक लिंकिंग की अक्षरशः और भावना को पूरा करता है और विरासत दृष्टिकोणों की तुलना में धोखाधड़ी के प्रति लचीलापन और ऑडिटेबिलिटी में सुधार करता है, जबकि पारिस्थितिकी तंत्र के परिपक्व होने पर भविष्य के संवर्द्धन (SPC) के लिए एक स्पष्ट मार्ग बनाए रखता है।

व्यवहार में, पासकीज़ डायनेमिक लिंकिंग को तब संतुष्ट करते हैं जब हम तीन चीजें करते हैं: हम यूज़र वेरिफिकेशन से पहले भुगतानकर्ता को राशि और प्राप्तकर्ता दिखाते हैं; हम एक ऑथेंटिकेशन कोड जेनरेट करते हैं जो उन सटीक विवरणों के लिए विशिष्ट होता है; और हम किसी भी बदलाव पर कोड को अमान्य कर देते हैं (RTS अनुच्छेद 5(1)(a–d))। यह उन सिद्धांतों को दर्शाता है जिन्हें नियामक पहले से ही स्थानीय बायोमेट्रिक्स के लिए स्वीकार करते हैं, इस अतिरिक्त सुविधा के साथ कि पासकीज़ OS-नेटिव हैं और बिना किसी अतिरिक्त ऐप के वेब और ऐप चैनलों पर काम करते हैं। ऑरिजिन बाइंडिंग के साथ संयुक्त होने पर, वे स्पूफ किए गए अनुरोधों को सतह पर नहीं लाते हैं - केवल मूल साइट या ऐप से वैध प्रॉम्प्ट यूज़र को दिखाई देते हैं।