पासकीज़ के साथ डायनामिक लिंकिंग: सिक्योर पेमेंट कन्फर्मेशन (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 पर, हमने यह पता लगाया कि पासकीज़ PSD2 द्वारा पेश किए गए स्ट्रॉन्ग कस्टमर ऑथेंटिकेशन (SCA) उपायों के साथ कैसे एकीकृत होते हैं। हमने विशेष रूप से बैंकिंग एप्लिकेशन तक पहुँचने के लिए SCA द्वारा आवश्यक प्रमाणीकरण तत्वों पर ध्यान केंद्रित किया। SCA की आवश्यकताएँ न केवल एप्लिकेशन तक पहुँचने पर लागू होती हैं, बल्कि दूरस्थ रूप से इलेक्ट्रॉनिक भुगतान लेनदेन शुरू करने और हस्ताक्षर करने पर भी लागू होती हैं। इसके अलावा, इन आवश्यकताओं के लिए डायनामिक लिंकिंग नामक एक तंत्र के उपयोग की आवश्यकता होती है। इस लेख में, हम डायनामिक लिंकिंग की व्याख्या करेंगे और यह जाँचेंगे कि आज और भविष्य में इस तंत्र को प्रभावी ढंग से लागू करने के लिए पासकीज़ का उपयोग कैसे किया जा सकता है।

डायनामिक लिंकिंग 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.

Enterprises trust Corbado to protect their users and make logins more seamless with passkeys. Get your free passkey consultation now.

Get free consultation

आइए पहले विभिन्न विकल्पों का विश्लेषण करें कि डायनामिक लिंकिंग में पासकीज़ का उपयोग कैसे किया जा सकता है।

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

Become part of our Passkeys Community for updates & support.

Join

एक अधिक उन्नत एकीकरण में WebAuthn चैलेंज में ही अतिरिक्त लेनदेन विवरण को एन्कोड करना शामिल है (जो तकनीकी रूप से PSD2/RTS द्वारा आवश्यक नहीं है)। यह विधि चैलेंज में अन्य यादृच्छिक डेटा के साथ, भुगतान प्राप्तकर्ता और राशि का एक क्रिप्टोग्राफ़िक हैश शामिल करने का सुझाव देती है। ऐसा करने से, प्रमाणीकरण प्रक्रिया न केवल पासकी के माध्यम से उपयोगकर्ता की पहचान की पुष्टि करती है, बल्कि लेनदेन विवरण की अखंडता को भी क्रिप्टोग्राफ़िक रूप से प्रमाणित करती है। यह दृष्टिकोण राशि या भुगतान प्राप्तकर्ता के विवरण के साथ किसी भी छेड़छाड़ को अंतिम भुगतान के बिंदु पर पता लगाने योग्य बनाकर सुरक्षा की एक अतिरिक्त परत प्रदान करता है। क्रिप्टोग्राफ़िक प्रमाण प्रमाणीकरण कोड का एक अपरिवर्तनीय हिस्सा बन जाता है, जो उच्च-जोखिम वाले लेनदेन वातावरण में विश्वास और सुरक्षा को बढ़ाता है (अधिक जानकारी यहाँ)।

आइए इन दो विकल्पों की सीमाओं और चुनौतियों का विश्लेषण करें।

डायनामिक लिंकिंग के संदर्भ में पासकीज़ का उपयोग करने की सीमाओं में से एक, विशेष रूप से भुगतान प्रमाणीकरण के लिए, ठोस दस्तावेज़ीकरण या आश्वासन की कमी है कि भुगतानकर्ता को भुगतान प्राप्तकर्ता की जानकारी के बारे में सटीक रूप से सूचित किया गया है।

जबकि पासकीज़ उपयोगकर्ता प्रमाणीकरण के लिए एक सुरक्षित तरीका प्रदान करते हैं, वे स्वाभाविक रूप से यह सत्यापित नहीं करते हैं कि सभी लेनदेन विवरण, विशेष रूप से भुगतान प्राप्तकर्ता से संबंधित, भुगतानकर्ता को सही ढंग से प्रदर्शित किए गए हैं या नहीं।

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

डायनामिक लिंकिंग में पासकीज़ को एकीकृत करने की सबसे महत्वपूर्ण सीमा फर्स्ट-पार्टी और थर्ड-पार्टी पंजीकरण के बीच के अंतर में उत्पन्न होती है।

फर्स्ट-पार्टी पेमेंट कॉन्टेक्स्ट क्या है?

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

फर्स्ट-पार्टी पेमेंट कॉन्टेक्स्ट पर मास्टरकार्ड के पासकी कार्यान्वयन के लिए कृपया हमारी ब्लॉग पोस्ट देखें।

थर्ड-पार्टी पेमेंट कॉन्टेक्स्ट क्या है?

थर्ड-पार्टी पेमेंट कॉन्टेक्स्ट में उपयोगकर्ता एक अलग डोमेन (जैसे amazon.com) पर चेकआउट प्रक्रिया में एक मर्चेंट पेज पर है और एक क्रेडिट कार्ड लेनदेन शुरू करना चाहता है:

• ✔️ केस 1 – उपयोगकर्ता के पास पहले से ही अपने जारीकर्ता / बैंक से एक पासकी है: मर्चेंट एक iframe दिखाता है जहाँ पासकी के साथ प्रमाणीकरण हो सकता है। IFRAME अंतर्निहित 3-डी सिक्योर 2 (3DSS/EMV 3DS) प्रक्रिया द्वारा दिखाया जाता है जो पहले से ही उन क्रेडिट कार्ड लेनदेन के लिए मौजूद है जिन्हें SCA और डायनामिक लिंकिंग का समर्थन करने की आवश्यकता है।

• ❌ केस 2 – उपयोगकर्ता के पास अपने जारीकर्ता / बैंक से कोई पासकी नहीं है: फिर से, मर्चेंट iframe दिखाता है। चूँकि अभी तक कोई पासकी उपलब्ध नहीं है, उपयोगकर्ता को मौजूदा प्रमाणीकरण कारकों (जैसे एसएमएस ओटीपी या उनके स्मार्टफोन पर नेटिव बैंकिंग ऐप) द्वारा प्रमाणित किया जाता है। इस बिंदु पर, एक सफल प्रमाणीकरण के बाद, उपयोगकर्ता के लिए एक पासकी पंजीकृत करने का यह आदर्श क्षण होगा, लेकिन WebAuthn मानक प्रतिबंधों के कारण इसकी अनुमति नहीं है। क्रॉस-ओरिजिन iframe में पासकीज़ का पंजीकरण अनुमत नहीं है (मुख्य पृष्ठ और iframe का डोमेन समान होना चाहिए)। निम्नलिखित स्क्रीनशॉट की तरह एक क्रमिक नामांकन असंभव होगा:

क्या भविष्य में क्रॉस-ओरिजिन iframes में पासकी पंजीकरण का समर्थन किया जाएगा?

जबकि पासकीज़ एक ही डोमेन के भीतर फर्स्ट-पार्टी पेमेंट कॉन्टेक्स्ट में डायनामिक लिंकिंग के लिए एक अच्छा समाधान प्रदान करते हैं, थर्ड-पार्टी पेमेंट कॉन्टेक्स्ट में, वे वर्तमान में WebAuthn लेवल 2 द्वारा समर्थित नहीं हैं। हालाँकि, अच्छी खबर यह है कि क्रॉस-ओरिजिन iframe समर्थन पहले से ही चल रहे WebAuthn लेवल 3 विनिर्देश में शामिल है (जो 2024 के अंत तक आम तौर पर उपलब्ध कराया जाएगा)। हालाँकि, ब्राउज़रों को अभी भी विनिर्देश के साथ तालमेल बिठाना है:

आज की स्थिति में, ऐसा लगता है कि 2024 तक, क्रॉस-ओरिजिन पासकीज़ के पंजीकरण के लिए कवरेज प्रमुख ब्राउज़रों में एक वास्तविकता बन सकता है, जो भुगतान के लिए पासकीज़ का उपयोग करने में सबसे महत्वपूर्ण तकनीकी सीमा को हटा देगा।

वेब पर भुगतान अनुभव को बेहतर बनाने के लिए W3C में Google द्वारा शुरू किए गए कार्य समूहों द्वारा कई प्रयास किए गए हैं (जैसे बेसिककार्ड, पेमेंटहैंडलर या पेमेंटमैनिफेस्ट)। अब तक किसी ने भी महत्वपूर्ण बाजार कवरेज और उपयोग हासिल नहीं किया है। धोखाधड़ी के खिलाफ बढ़ते विनियमन के साथ ईकॉमर्स लेनदेन के लिए भुगतान प्रक्रिया में घर्षण एक बड़ी चुनौती बनी हुई है। सिक्योर पेमेंट कन्फर्मेशन मानक जो Google और Stripe द्वारा शुरू किया गया था, वर्तमान में WebAuthn मानक पर आधारित सबसे आशाजनक मानक है।

सिक्योर पेमेंट कन्फर्मेशन (SPC) PSD2 SCA के सभी महत्वपूर्ण तत्वों को संबोधित करता है, जिसमें डायनामिक लिंकिंग की आवश्यकता भी शामिल है, और साथ ही UX अनुभव को बेहतर बनाने का प्रयास करता है।

• ब्राउज़र-नेटिव UX प्रदान करें: SPC विभिन्न मर्चेंट साइटों और रिलेइंग पार्टियों में एक सुसंगत और सुव्यवस्थित प्रमाणीकरण अनुभव प्रदान करने के लिए ब्राउज़र का लाभ उठाता है। इस दृष्टिकोण का उद्देश्य एक सुसंगत उपस्थिति और भुगतानकर्ता की जागरूकता की गारंटी देकर iframe में प्रस्तुत सामग्री के साथ आमतौर पर प्राप्त होने वाली लेनदेन सुरक्षा को बढ़ाना है:

उदाहरण https://www.w3.org/press-releases/2023/spc-cr/ से

• क्रिप्टोग्राफ़िक साक्ष्य प्रदान करें: मानक यह सुनिश्चित करता है कि उपयोगकर्ता द्वारा भुगतान विवरण की पुष्टि का क्रिप्टोग्राफ़िक प्रमाण उत्पन्न हो और WebAuthn असर्शन में शामिल हो, बिना जानकारी को WebAuthn चैलेंज में एन्कोड करने की आवश्यकता के।

• थर्ड-पार्टी नामांकन की अनुमति दें: WebAuthn लेवल 2 मानक के विपरीत, जहाँ एक ऑथेंटिकेटर का पंजीकरण फर्स्ट-पार्टी संदर्भ में होना चाहिए, SPC सीधे क्रॉस-ओरिजिन iframe से पासकीज़ के पंजीकरण को सक्षम बनाता है। यह क्षमता भुगतान पारिस्थितिकी तंत्र में सामान्य उपयोग के मामलों को संबोधित करती है और मर्चेंट्स और भुगतान प्रोसेसर के लिए आसान एकीकरण की सुविधा प्रदान करती है। जैसा कि हमने ऊपर चर्चा की है, यह कार्यक्षमता पहले से ही अंतर्निहित मानक के अगले संस्करण का हिस्सा है और इसलिए भविष्य में संभवतः SPC से हटा दी जाएगी।

• भुगतान का क्रॉस-ओरिजिन प्रमाणीकरण: SPC किसी भी मूल को एक लेनदेन के लिए एक असर्शन उत्पन्न करने की अनुमति देकर WebAuthn की उपयोगिता का विस्तार करता है, भले ही वह किसी अन्य रिलेइंग पार्टी से क्रेडेंशियल्स का लाभ उठाए (पृष्ठ छोड़ने की आवश्यकता के बिना)। इस मामले में, मर्चेंट / जारीकर्ता से एक iframe की भी आवश्यकता नहीं है। यह सुविधा उन परिदृश्यों में विशेष रूप से उपयोगी है जहाँ प्रमाणीकरण प्रक्रिया में कई पक्ष (मर्चेंट + जारीकर्ता / बैंक) शामिल होते हैं और असर्शन को सत्यापन के लिए मूल रिलेइंग पार्टी (खाता प्रदाता जैसे बैंक) तक पहुँचाया जा सकता है।

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

ये उद्देश्य ऑनलाइन भुगतानों की सुरक्षा और उपयोगकर्ता अनुभव दोनों को बेहतर बनाने के लिए SPC की प्रतिबद्धता को दर्शाते हैं, जिसका उद्देश्य डिजिटल भुगतान परिदृश्य में उच्च सुरक्षा मानकों को बनाए रखते हुए प्रमाणीकरण प्रक्रियाओं को सरल बनाना है।

आइए उन सभी संभावित प्रवाहों से गुजरें जिनकी SPC अनुमति देगा और उन्हें मानक पासकीज़ से तुलना करें, ताकि हम लाभों को समझ सकें।

जैसा कि हम यहाँ देख सकते हैं, सबसे महत्वपूर्ण अंतर मर्चेंट वेबसाइट पर एक iframe के भीतर पंजीकरण है जो अभी तक पासकीज़ द्वारा समर्थित नहीं है (ऊपर हमारी चर्चा देखें) और क्रॉस-ओरिजिन प्रमाणीकरण की पूरी तरह से नई संभावना है। आइए एक-एक करके उन पर विचार करें।

यहाँ मास्टरकार्ड के पेज पर सीधे एक SPC पासकी पंजीकृत करने का एक मॉक-अप उदाहरण है। जैसा कि आप यहाँ देख सकते हैं, इस मामले में एसएमएस ओटीपी के माध्यम से प्रमाणीकरण पूरा होने के ठीक बाद पासकी निर्माण की पेशकश की जाती है।

इस मामले में, संचार एक मानक पासकी पंजीकरण प्रक्रिया की तरह दिखेगा क्योंकि यह पूरी तरह से फर्स्ट-पार्टी संदर्भ में होता है।

_ https://developer.chrome.com/docs/payments/register-secure-payment-confirmation से लिया गया_

इस SPC पासकी का उपयोग अब एक मर्चेंट साइट पर प्रमाणीकरण के लिए, मर्चेंट साइट पर एक iframe में और क्रॉस-ओरिजिन प्रमाणीकरण के लिए किया जा सकता है (नीचे देखें)।

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

एक भुगतान लेनदेन के दौरान, जब 3DS प्रवाह शुरू किया जाता है, तो प्रमाणीकरण प्रक्रिया मर्चेंट की साइट (जैसे amazon.com) पर होस्ट किए गए एक iframe के माध्यम से सुगम होती है, लेकिन भुगतान सेवा प्रदाता या जारीकर्ता बैंक (जैसे mastercard.com) द्वारा नियंत्रित होती है। यह iframe ग्राहक के लिए मौजूदा प्रमाणीकरण कारकों का उपयोग करके अपनी पहचान प्रमाणित करने के लिए एक सुरक्षित वातावरण के रूप में कार्य करता है।

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

_ https://developer.chrome.com/docs/payments/register-secure-payment-confirmation से लिया गया_

https://spc-merchant.glitch.me/ पर, Google ने एक डेमो एप्लिकेशन स्थापित किया है जिसे विंडोज और मैक पर क्रोम के माध्यम से एक्सेस किया जा सकता है, जो यह दर्शाता है कि यह एक iframe के भीतर से कैसे काम करेगा:

यह सीधे बैंक की साइट के साथ खेलने की भी अनुमति देता है जो https://spc-rp.glitch.me/reauth के तहत होस्ट की गई है। इस उदाहरण में, मर्चेंट और जारीकर्ता / बैंक के बीच एपीआई के साथ किसी भी आउट-ऑफ-बैंड संचार की आवश्यकता नहीं है - सब कुछ ब्राउज़र द्वारा नियंत्रित किया जाता है। एक मौजूदा पासकी का उपयोग करके प्रमाणीकरण iframe के भीतर से उसी तरह काम करेगा।

निम्नलिखित उदाहरण में, हम क्रॉस-ओरिजिन प्रमाणीकरण देखते हैं जहाँ उपयोगकर्ता ने पहले ही मास्टरकार्ड के साथ एक SPC पासकी पंजीकृत कर ली है। उदाहरण मर्चेंट साइट (decorshop.com) क्रॉस-ओरिजिन प्रमाणीकरण को ट्रिगर कर सकती है। प्रमुख और महत्वपूर्ण अंतर यह है कि प्रमाणीकरण प्रक्रिया के दौरान मर्चेंट / जारीकर्ता पृष्ठ कभी भी दिखाई नहीं देता है। ऑपरेटिंग सिस्टम के साथ संयोजन में ब्राउज़र पूर्वनिर्धारित भुगतान UX (SPC मानक के ब्राउज़र कार्यान्वयन द्वारा प्रदान किया गया) और प्रमाणीकरण मोडल (WebAuthn मानक) प्रस्तुत करता है। मर्चेंट और जारीकर्ता / बैंक के बीच संचार पृष्ठभूमि में नियंत्रित किया जाता है।

मूल रूप से (आंशिक रूप से समायोजित): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (मास्टरकार्ड)

मूल रूप से (आंशिक रूप से समायोजित): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

क्रॉस-ओरिजिन प्रमाणीकरण का उपयोग करते समय, मर्चेंट मौजूदा क्रेडेंशियल्स के बारे में जानकारी का आदान-प्रदान करने के लिए किसी प्रकार के एपीआई के माध्यम से जारीकर्ता / बैंक के साथ संचार करता है (उपरोक्त अनुक्रम चार्ट में #2)। यदि क्रेडेंशियल्स मौजूद हैं और उपयोगकर्ता का ब्राउज़र SPC का समर्थन करता है, तो प्रमाणीकरण शुरू होता है। अंत में, असर्शन को EMV 3DS जैसे मौजूदा प्रोटोकॉल के माध्यम से जारीकर्ता / बैंक को वापस लौटाया जाता है, जहाँ असर्शन को अंत में क्रिप्टोग्राफ़िक रूप से सत्यापित किया जा सकता है (#16)।

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

सिक्योर पेमेंट कन्फर्मेशन (SPC) मानक ऑनलाइन भुगतान प्रमाणीकरण की दुनिया में एक दिलचस्प विकास है, जिसका उद्देश्य सुरक्षा को बढ़ाते हुए उपयोगकर्ता अनुभव को सुव्यवस्थित करना है। आज तक, Google Chrome एकमात्र प्रमुख ब्राउज़र है जो किसी न किसी रूप में SPC का समर्थन करता है। हालाँकि, यह आश्चर्य की बात नहीं है क्योंकि मानक आंशिक रूप से Google द्वारा शुरू किया गया है। Apple के Safari और Mozilla Firefox जैसे अन्य प्रमुख ब्राउज़रों से, प्रतिबद्धता की एक उल्लेखनीय कमी है और SPC का समर्थन करने की उनकी योजनाओं के बारे में कोई स्पष्ट संकेत नहीं है। विशेष रूप से Apple अपने स्वयं के मालिकाना मानक Apple Pay को आगे बढ़ाता है और अन्य भुगतान मानकों में रुचि नहीं रखता है।

SPC का WebAuthn के साथ संबंध ने विकास प्रक्रिया को और अधिक कठिन बना दिया है। ऐसा इसलिए है क्योंकि SPC मानक में किसी भी वृद्धि या संशोधन का सावधानीपूर्वक मूल्यांकन करने की आवश्यकता है ताकि अतिरेक को रोका जा सके और यह सुनिश्चित किया जा सके कि वे मौजूदा क्षमताओं पर वास्तविक सुधार प्रदान करते हैं। लक्ष्य SPC को भुगतान प्रक्रिया के भीतर विशिष्ट आवश्यकताओं की पूर्ति के लिए परिष्कृत करना है जो WebAuthn द्वारा पूरी तरह से कवर नहीं किए गए हैं, जैसे कि चेकआउट प्रवाह में सीधा एकीकरण और एक अधिक उपयोगकर्ता-अनुकूल प्रमाणीकरण अनुभव प्रदान करना जो विभिन्न मर्चेंट साइटों पर निर्बाध रूप से काम कर सकता है।

जैसे-जैसे SPC विकसित होता जा रहा है, विभिन्न ब्राउज़रों में इसका अपनाया जाना व्यापक कार्यान्वयन के लिए महत्वपूर्ण होगा। Google जैसे प्रमुख खिलाड़ियों की भागीदारी एक सकारात्मक दिशा का संकेत देती है, लेकिन ऑनलाइन भुगतान उद्योग में SPC को एक मानक के रूप में स्थापित करने के लिए व्यापक समर्थन आवश्यक होगा।

ऊपर उल्लिखित चुनौतियों, विशेष रूप से भुगतानकर्ता की जागरूकता के आसपास, ने WebAuthn वर्किंग ग्रुप में एक तथाकथित कन्फर्मेशन एक्सटेंशन (जिसे पहले “txAuthSimple” के नाम से जाना जाता था) पर चल रहे काम को प्रेरित किया है। इसका उद्देश्य या तो ऑथेंटिकेटर या ब्राउज़र/ओएस (एक विशेषाधिकार प्राप्त यूआई में) को उपयोगकर्ता को लेनदेन विवरण प्रदर्शित करने की अनुमति देना है और यह सुनिश्चित करना है कि रिलेइंग पार्टी को क्रिप्टोग्राफ़िक प्रमाण प्राप्त हो कि उपयोगकर्ता ने वास्तव में इन विवरणों की पुष्टि की है। यह सीधे अनुभाग 3.3.1 में वर्णित “गारंटीकृत उपयोगकर्ता जागरूकता की कमी” की समस्या को संबोधित करता है।

जिस तरह सिक्योर पेमेंट कन्फर्मेशन (SPC) एक समर्पित, ब्राउज़र-चालित संवाद प्रदान करता है, उसी तरह कन्फर्मेशन एक्सटेंशन “जो आप देखते हैं, उसी पर आप साइन करते हैं” (WYSIWYS) चिंता का समाधान करता है। इसके मुख्य उद्देश्य हैं:

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

एक्सटेंशन मौजूदा WebAuthn एक्सटेंशन संरचनाओं में एक नया फ़ील्ड जोड़ता है। रिलेइंग पार्टियाँ confirmation नामक एक सरल पाठ स्ट्रिंग (वैकल्पिक बुनियादी स्वरूपण के साथ) की आपूर्ति करती हैं:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

जब क्लाइंट (ब्राउज़र) इसे प्राप्त करता है, तो यह:

1. उपयोगकर्ता को एक विशेष पुष्टिकरण संवाद के साथ संकेत देता है (ताकि वे जान सकें कि यह एक बुनियादी लॉगिन से अधिक है)।
2. यदि ऑथेंटिकेटर एक्सटेंशन का समर्थन करता है तो उसी स्ट्रिंग को CBOR डेटा के रूप में ऑथेंटिकेटर को पास करता है।
3. किसी भी ऑथेंटिकेटर आउटपुट को रिलेइंग पार्टी को वापस करता है।

यदि ऑथेंटिकेटर पाठ प्रदर्शित करने का समर्थन करता है, तो उसे उपयोगकर्ता सत्यापन पूरा करने से पहले उस पाठ को (उदाहरण के लिए, अपनी स्क्रीन या विश्वसनीय यूआई पर) दिखाना होगा। फिर यह अपने हस्ताक्षरित आउटपुट में उसी स्ट्रिंग को शामिल करता है।

रिलेइंग पार्टी की ओर, सत्यापन चरण यह सुनिश्चित करते हैं कि लौटाया गया confirmation पाठ भेजे गए पाठ से मेल खाता है। यदि ऑथेंटिकेटर एक्सटेंशन आउटपुट गायब है, लेकिन रिलेइंग पार्टी नीति एक फ़ॉलबैक की अनुमति देती है, तो रिलेइंग पार्टी क्लाइंट डेटा से confirmation मान पर भरोसा कर सकती है - यह दर्शाता है कि ब्राउज़र ने ऑथेंटिकेटर के बजाय पाठ प्रदर्शित किया है।

इस एक्सटेंशन में भुगतान प्राप्तकर्ता और राशि को एम्बेड करके, उपयोगकर्ता ठीक वही देखता है जिसे वे एक विश्वसनीय प्रदर्शन पर अधिकृत कर रहे हैं। उपयोगकर्ता का हस्ताक्षर अब न केवल एक हैश किए गए चैलेंज को दर्शाता है, बल्कि सटीक लेनदेन पाठ को भी दर्शाता है। यह PSD2 की डायनामिक-लिंकिंग आवश्यकता के लिए विशेष रूप से मूल्यवान है, क्योंकि:

• प्रदर्शन के बाद लेनदेन विवरण का कोई भी बेमेल या संशोधन हस्ताक्षर को अमान्य कर देता है।
• रिलेइंग पार्टी यह साबित कर सकती है कि उपयोगकर्ता को हस्ताक्षर के समय सही लेनदेन विवरण दिया गया था, जो PSD2 की “भुगतानकर्ता जागरूकता” आवश्यकता को केवल चैलेंज में डेटा हैश करने की तुलना में कहीं अधिक मजबूती से पूरा करता है।

जबकि कन्फर्मेशन एक्सटेंशन अभी भी चर्चा में है, यह अधिक सुरक्षित और उपयोगकर्ता-अनुकूल लेनदेन प्रवाह की दिशा में एक महत्वपूर्ण कदम का प्रतिनिधित्व करता है। इसे सीधे WebAuthn विनिर्देश में बनाकर, यह प्रदान करता है:

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

अधिक तकनीकी विवरण के लिए, आप चल रही चर्चा पर एक नज़र डाल सकते हैं: GitHub पुल अनुरोध #2020। सारांश में, कन्फर्मेशन एक्सटेंशन मानक पासकी-आधारित प्रवाह में अंतिम प्रमुख अंतर को भी बंद कर सकता है: उपयोगकर्ता ने अपनी सहमति देते समय ठीक क्या देखा, इसका क्रिप्टोग्राफ़िक प्रमाण प्रदान करना, यद्यपि सिक्योर पेमेंट कन्फर्मेशन की तुलना में कम संरचित। यदि यह ब्राउज़रों और ऑथेंटिकेटर विक्रेताओं के बीच कर्षण प्राप्त करता है, तो यह PSD2 डायनामिक लिंकिंग के तहत आवश्यक WYSIWYS सुरक्षा गारंटी देने के लिए एक अत्यधिक मानकीकृत तरीका बन सकता है - और उससे भी आगे।

यद्यपि SPC और कन्फर्मेशन एक्सटेंशन WebAuthn में डायनामिक लिंकिंग को मजबूत करने का एक साझा लक्ष्य साझा करते हैं, वे दायरे और दृष्टिकोण में भिन्न हैं। नीचे दी गई तालिका इनमें से कुछ अंतरों पर प्रकाश डालती है:

संक्षेप में, SPC एक व्यापक भुगतान समाधान* की पेशकश करने का प्रयास करता है और अपने प्रवाह के हिस्से के रूप में डायनामिक लिंकिंग* को भी शामिल करता है। इस बीच, कन्फर्मेशन एक्सटेंशन*, मानक WebAuthn संदेशों के भीतर “जो आप देखते हैं वही आप साइन करते हैं” आवश्यकता को संबोधित करता है, बिना पूर्ण भुगतान प्रवाह को लागू किए। कोई भी दृष्टिकोण PSD2 अनुपालन की सुविधा प्रदान कर सकता है, लेकिन प्रत्येक वास्तविक दुनिया के लाभ प्रदान करने के लिए ब्राउज़र और ऑथेंटिकेटर समर्थन पर निर्भर करता है।

इसलिए जारीकर्ताओं, बैंकों और वित्तीय संस्थानों के लिए हमारी सिफारिश यह है कि वे सावधानीपूर्वक मूल्यांकन करें कि किन उपयोग के मामलों को कवर करने की आवश्यकता है और पारिस्थितिकी तंत्र के विकास की निगरानी करें क्योंकि पासकीज़ की आसानी मौजूदा SCA और डायनामिक लिंकिंग समाधानों पर उनके UX को बेहतर बनाने के लिए पर्याप्त दबाव डालेगी। ग्राहक वेब में बायोमेट्रिक समाधानों की मांग करेंगे। इस समय, हमारी परिचालन सिफारिश है:

• ✔️ जारीकर्ता / बैंक वेबसाइट पर शुरू किए गए भुगतानों के लिए पासकीज़: पासकीज़ जारीकर्ताओं / बैंकों के लिए अपनी वेबसाइटों और ऐप्स में सीधे डायनामिक लिंकिंग को लागू करने के लिए एक बहुत अच्छा समाधान है। उन्हें उच्च-जोखिम वाले भुगतानों के लिए सुरक्षा को और बढ़ाने के लिए पुश नोटिफिकेशन, ईमेल / एसएमएस ओटीपी या टीओटीपी जैसे अन्य प्रमाणीकरण विकल्पों के साथ जोड़ा जा सकता है। बेशक, SCA अनुपालन के संबंध में विचार हमेशा इस चर्चा का हिस्सा होना चाहिए (हमारी पासकीज़ और SCA पर 4-भागों की श्रृंखला भी देखें)।

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

• ❌ मर्चेंट पेजों पर भुगतानों के लिए पासकीज़: मर्चेंट पेजों पर भुगतानों के लिए पासकीज़ को रोल आउट करना अभी तक संभव नहीं है। क्रॉस-ओरिजिन उपयोग के मामले अभी भी विकास में हैं लेकिन 2024 के अंत में एक व्यवहार्य विकल्प हो सकते हैं। हालांकि, मर्चेंट पेजों पर प्रमाणीकरण के लिए पासकीज़ का उपयोग करना आज पहले से ही एक बढ़िया विचार है और इसका उपयोग पासकीज़ एकत्र करना शुरू करने के लिए भी किया जा सकता है जिनका उपयोग भविष्य में भुगतानों के लिए भी किया जा सकता है।

• ❌ डायनामिक लिंकिंग के लिए SPC पासकीज़ या कन्फर्मेशन एक्सटेंशन: SPC मानक अभी तक उत्पादन वातावरण में उपयोग किए जाने के लिए एक परिपक्व स्थिति और समर्थन तक नहीं पहुंचा है।

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

Why are Passkeys important?

Passkeys for Enterprises

Passwords & phishing put enterprises at risk. Passkeys offer the only MFA solution balancing security and UX. Our whitepaper covers implementation and business impact.

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

जब हम डायनामिक लिंकिंग के लिए पासकीज़ की समीक्षा करते हैं, तो यह स्पष्ट है कि जबकि पासकीज़ SCA और डायनामिक लिंकिंग का पालन करने में मदद कर सकते हैं, WebAuthn मानक के साथ तीसरे पक्ष की सेवाओं में तकनीकी एकीकरण, जो मूल रूप से फर्स्ट-पार्टी संदर्भों के लिए डिज़ाइन किया गया था, कुछ चुनौतियाँ प्रस्तुत करता है। ये मानक धीरे-धीरे तीसरे पक्ष के परिदृश्यों का बेहतर समर्थन करने के लिए विकसित हो रहे हैं, जो उनके अनुप्रयोग में अधिक लचीलेपन की ओर एक बदलाव का प्रदर्शन करते हैं। सिक्योर पेमेंट कन्फर्मेशन (SPC) इस अनुकूलन को आगे बढ़ाने का प्रयास करता है, जिसका उद्देश्य विभिन्न मर्चेंट साइटों पर अधिक उपयोगकर्ता-अनुकूल और निर्बाध इंटरैक्शन को शामिल करके भुगतान प्रमाणीकरण प्रक्रियाओं को बढ़ाना है।

हालांकि, SPC मानक या कन्फर्मेशन एक्सटेंशन की प्रगति और व्यापक स्वीकृति प्रमुख ब्राउज़रों द्वारा इसे अपनाने पर बहुत अधिक निर्भर करती है - एक प्रक्रिया जो धीमी रही है, जिसमें Google Chrome वर्तमान में एकमात्र समर्थक है। यह धीमी अपनाने की दर संभावित रूप से विशेष रूप से SPC को अपनी वर्तमान स्थिति से आगे बढ़ने से रोक सकती है जब तक कि अधिक ब्राउज़र इसे एकीकृत करना शुरू न करें। पासकीज़ का चल रहा विकास और बढ़ता कर्षण एक आशाजनक दिशा का सुझाव देता है जहाँ हार्डवेयर सुरक्षा मॉड्यूल (HSM) जैसे कि सिक्योर एन्क्लेव, TEEs, और TPMs पर निर्भर सिस्टम भी भुगतान अनुप्रयोगों के लिए एक महत्वपूर्ण भूमिका निभाएंगे क्योंकि ये प्रौद्योगिकियाँ बढ़ी हुई सुरक्षा प्रदान करती हैं जो भुगतानों की डायनामिक लिंकिंग को न केवल बैंकिंग साइटों पर शुरू किए गए लेनदेन के लिए बल्कि तीसरे पक्ष के मर्चेंट प्लेटफार्मों पर भी अधिक व्यावहारिक और आरामदायक बना सकती हैं।

पासकीज़ की ऑनलाइन भुगतान प्रक्रियाओं तक अपनी उपयोगिता का विस्तार करने की क्षमता वेब-आधारित लेनदेन को सुरक्षित करने और सामान्य रूप से इंटरनेट को एक सुरक्षित स्थान बनाने में एक महत्वपूर्ण पहलू पर प्रकाश डालती है।