EUDI Wallet इंटीग्रेशन: अपना रूट कैसे चुनें (2026 गाइड)

अंतिम समीक्षा: 31 अक्टूबर 2026 · कानूनी सलाह नहीं

European Digital Identity (EUDI) Wallet इस सर्दी एक वास्तविक समय-सीमा तक पहुँच रहा है: हर Member State को 24 दिसंबर 2026 तक एक wallet देना है, और इसे स्वीकार करने वाली कंपनियों के लिए register नियम भी उसी दिन लागू होते हैं.^[1][2] अधिकांश टीमों के लिए सवाल अब "यह क्या है" से बदलकर "हम इससे कैसे जुड़ें" हो गया है.

यह गाइड EUDI Wallet एकीकरण के चार रास्तों की तुलना करती है, अलग करती है कि आप क्या सौंप सकते हैं और क्या आपके पास रहता है, और हर क्षमता को उसके पीछे के नियम से जोड़ती है. यह लागू कानून और Architecture and Reference Framework (ARF), यानी तकनीकी ब्लूप्रिंट, के संस्करण 3.0.0 को पढ़ती है, जिसमें intermediaries पर जुलाई 2026 के बदलाव भी शामिल हैं.^[3][6]

अगर आपको पहले बुनियादी जानकारी चाहिए, तो EUDI Wallet relying party: पंजीकरण, प्रमाणपत्र और दायित्व और OpenID4VP verifier गाइड पढ़ें. कानून के लिए, eIDAS 2 की व्याख्या देखें.

EUDI Wallet एकीकरण को वास्तव में क्या करना होता है

पाँच काम हैं. कोई सेवा का पंजीकरण करता है. कोई वे keys रखता है जो साबित करती हैं कि कौन माँग रहा है. कोई हस्ताक्षरित अनुरोध भेजता है. कोई लौटकर आई जानकारी का सत्यापन करता है. कोई रिकॉर्ड रखता है. हर रास्ता इन्हें अलग तरह से बाँटता है.

ARF उस सिस्टम को Relying Party Instance कहता है जो wallets से बात करता है. ARF में यह एक access certificate से प्रमाणीकरण करता है, जिसकी private key "is securely stored in the hardware of the Relying Party Instance" (Relying Party Instance के hardware में सुरक्षित रूप से संग्रहीत है).^[6] दूसरा object, registration certificate, एक इच्छित उपयोग और उसके लिए पंजीकृत attributes बताता है.^[1][6] Relying party हर presentation request में इनमें से एक by value शामिल करती है.^[7]

2026 के दो बदलाव खरीद के निर्णय को बदलते हैं. 15 जुलाई 2026 के Implementing Regulation (EU) 2026/1730 ने पंजीकरण नियमों में संशोधन किया. Member States के लिए अब registration certificates जारी करने हेतु कम से कम एक certificate authority को अधिकृत करना अनिवार्य है, और इन certificates का जारी किया जाना स्वचालित होना अनिवार्य है.^[3] इसने Annex I point 16 भी जोड़ा, यानी उस relying party से जुड़ाव जिसकी सेवा intermediary करता है, जिसे Annex II के तहत access certificate में होना चाहिए.^[3]

वे तारीखें जो आपकी योजना तय करती हैं

1. 11 अगस्त 2026नियम संशोधित2026/1730 लागू, हमारी गणना: 22 जुलाई के प्रकाशन के 20 दिन बाद.
2. 24 दिसंबर 2026Wallets देय2025/848 के पंजीकरण नियम लागू.
3. 10 जुलाई 2027AMLR लागूअधिकांश बाध्य संस्थाओं पर आउटसोर्सिंग और रिकॉर्ड नियम लागू.
4. 24 दिसंबर 2027स्वीकृतिअनुच्छेद 5f(2) निजी relying parties (हमारी गणना).
5. 11 अगस्त 2028Certificate जाँचWallets को registration certificates का प्रमाणीकरण और सत्यापन करना होगा.

तारीखें Regulation (EU) No 910/2014, 2025/848, 2026/1730, 2026/1731 और AMLR से. 24 दिसंबर 2027 हमारी गणना है: कार्यान्वयन अधिनियमों के लागू होने के 36 महीने बाद (4 दिसंबर 2024 को प्रकाशित, 20 दिन बाद लागू).^{[1][2][3][4][5][9]}

कानूनी आधार अनुच्छेद 5f(2) में है. यह उन निजी relying parties पर लागू होता है जिन्हें कानून या अनुबंध के तहत online identification के लिए strong user authentication का उपयोग करना अनिवार्य है, ऐसे क्षेत्रों में जिनमें banking, ऊर्जा और स्वास्थ्य शामिल हैं, और यह "only upon the voluntary request of the user" (केवल उपयोगकर्ता के स्वैच्छिक अनुरोध पर) लागू होता है.^[1] बहुत बड़े online platforms का अनुच्छेद 5f(3) के तहत अलग दायित्व है, जिसके लिए पाठ में कोई अलग तारीख नहीं है.^[1] पूरे कैलेंडर के लिए EUDI Wallet की हर समय-सीमा देखें.

EUDI Wallet एकीकरण के चार रास्ते

तालिका रास्तों को इस आधार पर वर्गीकृत करती है कि wallet से कौन और किस कानूनी भूमिका में बात करता है. प्रयास और नियंत्रण हमारा आकलन है, कोई कानूनी कसौटी नहीं.

Route 1: अपना खुद का verifier बनाएं

Relying Party Instance आप चलाते हैं। European Commission एक reference implementation प्रकाशित करता है, जिसमें remote verifier और proximity verifier बनाने के गाइड हैं, और उसका verifier endpoint Apache 2.0 के तहत लाइसेंस प्राप्त है।^[14][15] फिर भी hardware में रखी keys, हर instance और service के लिए एक certificate, trusted lists का download, और specifications बदलने पर upgrades की ज़िम्मेदारी आपकी ही रहती है।^[6][7]

यह बड़े wallet volumes के लिए उपयुक्त है, या ऐसी risk team के लिए जो किसी third party को प्रस्तुत attributes देखने नहीं देगी।

Route 2: एक relying party intermediary

अनुच्छेद 5b(10) इस मॉडल को कानूनी रूप देता है। बाकी ARF स्पष्ट करता है: intermediary एक "Relying Party का विशेष वर्ग" है जो relying party की ओर से उसके कार्य करता है, और ग्राहक को "access certificate की आवश्यकता नहीं होगी"।^[6] आपको फिर भी पंजीकरण कराना होता है, क्योंकि intermediary को यह सुनिश्चित करना होता है कि हर ग्राहक उस सदस्य राज्य में पंजीकृत हो जहाँ वह ग्राहक स्थापित है।^[7]

मार्ग 3: पहचान या ऑर्केस्ट्रेशन प्लेटफ़ॉर्म

"प्लेटफ़ॉर्म" एक व्यावसायिक शब्द है, जो अनुच्छेद 5b(10) में नहीं है। वॉलेट वाले हिस्से में प्लेटफ़ॉर्म या तो intermediary होता है, अपनी सभी सीमाओं के साथ, या आपके अपने instance का host। इसका लाभ यह है कि यह कई तरीकों को एक ही एकीकरण से route करता है। जोखिम यह मान लेना है कि प्लेटफ़ॉर्म दस्तावेज़ों के लिए जो करता है, जैसे वर्षों तक साक्ष्य संग्रहीत करना, वह वॉलेट पर भी लागू होता है। ऐसा ज़रूरी नहीं है।

मार्ग 4: वॉलेट प्रदाता या ट्रस्ट सेवा टूलिंग

वॉलेट प्रदाता और ट्रस्ट सेवा प्रदाता भी सॉफ़्टवेयर बेचते हैं। यह तब उपयोगी है जब आपको qualified signatures चाहिए या आप attestations जारी करना चाहते हैं। पंजीकरण नियम इन गतिविधियों को अलग entitlements के रूप में सूचीबद्ध करते हैं, जैसे QEAA_Provider और QCert_for_ESig_Provider, और सामान्य व्यवसाय के लिए Service_Provider।^[2] यदि टूल आपकी ओर से वॉलेट के साथ संपर्क करता है, तो उसे intermediary नियमों के आधार पर परखें।

क्या आपके पास रहता है, और आप क्या सौंप सकते हैं

अनुच्छेद 5b(10)Regulation (EU) No 910/2014

"relying parties की ओर से कार्य करने वाले intermediaries को relying parties माना जाएगा और वे लेनदेन की सामग्री से संबंधित डेटा संग्रहीत नहीं करेंगे।"

स्रोत: EUR-Lex, समेकित पाठ^[1]

अगर आपको relying party "माना" जाता है, तब भी आपके अपने दायित्व समाप्त नहीं होते। अनुच्छेद 5b(9) relying parties को उनके द्वारा माँगे गए person identification data और attestations के प्रमाणीकरण और सत्यापन की प्रक्रिया पूरी करने के लिए ज़िम्मेदार बनाता है।^[1] ARF यह बँटवारा अनुबंध पर छोड़ता है: "intermediary और उसकी सेवाओं का उपयोग करने वाली हर Relying Party को इस पर सहमत होना होगा कि intermediary कौन से सत्यापन करेगा"।^[6] रजिस्ट्रार इस संबंध का प्रमाण माँग सकता है, जैसे हस्ताक्षरित अनुबंध या mandate।^[6]

विनियमित फ़र्मों पर तीन और परतें लागू होती हैं। Anti-Money Laundering Regulation (AMLR) बाध्य संस्थाओं को कार्य आउटसोर्स करने देता है, लेकिन उन्हें पहले पर्यवेक्षक को सूचित करना होगा और वे "पूरी तरह उत्तरदायी" रहती हैं।^[9] Digital Operational Resilience Act वित्तीय संस्थाओं को ICT अनुबंधों के तहत "पूरी तरह ज़िम्मेदार" रखता है।^[11] General Data Protection Regulation (GDPR) पर्याप्त गारंटी वाले प्रोसेसर की मांग करता है।^[10] हमने जो भी पाठ पढ़ा, उसमें यह नहीं बताया गया कि मध्यस्थ प्रोसेसर है या नियंत्रक, इसलिए अपना विश्लेषण अनुबंध में दर्ज करें।

मध्यस्थ कैसे काम करता है, और प्रमाणपत्रों की संख्या क्यों मायने रखती है

मध्यस्थ के ज़रिए प्रस्तुति, ARF §6.6.5 और Topic 52 से सरल रूप में।^[6][7]

पहला, उपयोगकर्ता आपका व्यापारिक नाम देखता है, विक्रेता का नहीं, हालाँकि वॉलेट मध्यस्थ को लॉग करता है, ताकि उपयोगकर्ता बाद में उसे ढूँढ सके।^[6] दूसरा, वॉलेट पंजीकरण प्रमाणपत्र के पहचानकर्ताओं की तुलना एक्सेस प्रमाणपत्र के पहचानकर्ताओं से करता है, और बेमेल होने पर लेन-देन रुक सकता है।^[6] तीसरा, आपके और मध्यस्थ के बीच का इंटरफ़ेस ARF के दायरे से बाहर है, और ARF एट्रिब्यूट के एंड-टू-एंड एन्क्रिप्शन की मांग नहीं करता, इसलिए काफ़ी संभव है कि विक्रेता हर एट्रिब्यूट देख ले।^[6]

ARF का गणित ही मुख्य बात है। कार्यान्वयन विनियम 2026/1730 पंजीकरण डेटा में सेवा पाने वाली relying party से संबंध जोड़ता है, और ARF v3.0.0 में एक्सेस प्रमाणपत्र उस संबंध को दर्शाता है, इसलिए सेवा पाने वाली relying party के लिए, मध्यस्थ "अपनी हर मध्यस्थ-सेवा प्राप्त रिलाइंग पार्टी के लिए एक्सेस प्रमाणपत्रों का अलग सेट प्राप्त करता है"।^[3][6] जिस विक्रेता ने जुलाई 2026 से पहले साझा प्रमाणपत्र मॉडल बताया था, उसे आपको अपना नया डिज़ाइन दिखाना होगा। पैमाना जोखिम को केंद्रित करता है: अगर आपके मध्यस्थ की Access Certificate Authority निलंबित होती है, तो उसके प्रमाणपत्र रद्द हो जाते हैं, और आप एट्रिब्यूट का अनुरोध नहीं कर सकते "भले ही उसका पंजीकरण अभी भी वैध हो"।^[7] आपको किसी दूसरे मध्यस्थ पर जाना होगा या इंतज़ार करना होगा, इसलिए निकास योजना एक परिचालन नियंत्रण है।

साक्ष्य की समस्या: हटाना बनाम रखना

OIA_16 किसी Relying Party Instance से कहता है कि वह सभी unique elements हटा दे। इस सूची में attestation provider का signature भी शामिल है। साथ ही, इन्हें "Relying Party या किसी अन्य पक्ष को" न भेजे।^[7] इसलिए signed wallet response को आपके audit trail के रूप में रखने के वादे की जांच जरूरी है, चाहे वह वादा कोई भी vendor करे। ARF एक framework है, कानूनी अधिनियम नहीं। यह पांच वर्ष की retention duty के संदर्भ में "जरूरत न रहने" को परिभाषित नहीं करता। अपने कानूनी सलाहकार से पूछें और, यदि आप विनियमित हैं, तो अपने पर्यवेक्षक से भी।

नीचे हमारा सुझाया गया डिज़ाइन है। इसे जांचें, यह कोई नियम नहीं है।

विक्रेता को कौन-सी क्षमताएँ दिखानी होंगी, और हर क्षमता के पीछे का नियम

इस तालिका को request for proposal के तकनीकी परिशिष्ट के रूप में, या अपने स्वयं के निर्माण के लिए उपयोग करें।

OpenID Foundation ने अपने OpenID for Verifiable Presentations (OpenID4VP) अनुरूपता परीक्षण 7 अगस्त 2026 को स्व-प्रमाणन के लिए खोल दिए। सत्यापनकर्ता इन्हें निःशुल्क चला सकते हैं। स्व-प्रमाणन प्रकाशित करने पर शुल्क लगता है।^[12] Commission का Functional Conformance Assessment Framework अभी भी "सक्रिय विकास के अधीन" है, और इसकी प्रारंभिक परीक्षणाधीन प्रणाली Wallet Solution है। इसलिए अभी इससे relying party बैज की अपेक्षा न करें।^[13] फ़ॉर्मेट के बारे में: व्यक्ति पहचान डेटा (PID) क्रेडेंशियल mdoc और SD-JWT VC दोनों में जारी होना चाहिए, लेकिन अन्य अनुप्रमाणनों को एक-एक करके जाँचें। हमारी फ़ॉर्मेट तुलना यह अंतर समझाती है।^[7]

वॉलेट और गैर-वॉलेट रूटिंग

अनुच्छेद 5a(15) कहता है कि वॉलेट का उपयोग "स्वैच्छिक होगा" और "अन्य मौजूदा पहचान और प्रमाणीकरण साधनों से सार्वजनिक और निजी सेवाओं तक पहुँच संभव बनी रहेगी"।^[1] इसलिए वॉलेट कभी भी आपका एकमात्र रास्ता नहीं हो सकता। AMLR अनुच्छेद 22(6) भी पहचान दस्तावेज़ों या substantial या high स्तर की इलेक्ट्रॉनिक पहचान की अनुमति देता है।^[9]

एक रूटिंग डिज़ाइन जो हर रास्ता खुला रखता है। स्थिति-अज्ञात मार्ग VCR_14 के अधीन है।^[1][7]

पोर्ट्रेट 11 अगस्त 2028 से ही अनिवार्य PID डेटा बन सकता है, और सदस्य देश उपयोगकर्ताओं को इसे देने से मना करने की अनुमति दे सकते हैं। इसलिए जो डिज़ाइन वॉलेट से फ़ेस मैचिंग पर निर्भर है, वह हमेशा काम नहीं करेगा।^[5] होल्डर बाइंडिंग पर हमारा लेख बताता है कि कब केवल वॉलेट काफ़ी है और कब लाइवनेस जोड़नी चाहिए। फ़ील्ड और पहचानकर्ताओं में राष्ट्रीय अंतर 27+ राष्ट्रीय वॉलेट स्वीकार करना में हैं, और रोलआउट की स्थिति देश ट्रैकर में है। विनियमित ऑनबोर्डिंग के लिए AMLR और EUDI Wallet पढ़ें।

कंपनी के प्रकार के अनुसार रास्ता चुनना

यह एक शुरुआती बिंदु है: फ़ैसला आपके कानूनी सलाहकार और आपकी मात्रा तय करती है।^[1]

वेंडर से लिखित में क्या पूछें

रजिस्टर के नियम 24 दिसंबर 2026 से लागू होते हैं, इसलिए पंजीकृत सेवा के किसी भी दावे के पीछे की रजिस्टर प्रविष्टि माँगें।^[2]

इस महीने क्या करें

• हर विधिक इकाई के लिए लिखित में पुष्टि करें कि अनुच्छेद 5f(2) लागू होता है या 5f(3)।^[1]
• हर उपयोग के मामले को उसकी ज़रूरत की न्यूनतम विशेषताओं के साथ सूचीबद्ध करें।
• अपने रजिस्ट्रार और उसकी राष्ट्रीय पंजीकरण नीति का पता लगाएँ।^[2]
• अपनी प्रतिधारण दायित्वों के संदर्भ में OIA_16 के बारे में विधिक सलाहकार से पूछें।^[7][9]
• अज्ञात निरसन स्थिति के लिए नीति लिखें।^[7]
• यदि कोई बाध्य संस्था आउटसोर्स करेगी, तो पर्यवेक्षक को भेजी जाने वाली सूचना का मसौदा तैयार करें।^[9]
• आज आपके पास मौजूद तरीकों से फ़ॉलबैक मार्ग बनाएँ।

EUDI Wallet नीतियों और नियंत्रणों पर हमारी सहयोगी पोस्ट इन चरणों को स्वामियों और साक्ष्य के साथ एक नियंत्रण मैट्रिक्स में बदलती है।

EUDI Wallet एकीकरण में Didit कैसे मदद करता है

EUDI Wallet स्वीकृति जल्द आ रही है, अभी कोई तारीख या मूल्य तय नहीं है।^[17] हमारा दृष्टिकोण EUDI Wallet समाधान पृष्ठ पर देखें, जिसका कथन है "आज एकीकृत करें, और वॉलेट आने पर भी इसे बनाए रखें"।

आज जो मौजूद है, वह इस गाइड का बाकी प्रवाह है। Didit दस्तावेज़ कैप्चर के साथ MitID, BankID Sweden, Finnish Trust Network, Smart-ID और Mobile-ID चलाता है, और एक कॉन्फ़िगर किया गया दस्तावेज़ फ़ॉलबैक भी देता है।^[18] eID सत्यापन देखें। वर्कफ़्लो देश और परिणाम के अनुसार शाखाओं में बँटते हैं, वेबहुक हस्ताक्षरित होते हैं, और प्रतिधारण 1 महीने से 10 वर्ष तक कॉन्फ़िगर किया जा सकता है।^[19][20][21] Didit डेटा प्रोसेसर के रूप में कार्य करता है और नियंत्रक आप बने रहते हैं।^[22] Didit के पास SOC 2 Type 1 और Type 2 रिपोर्ट, ISO/IEC 27001:2022 प्रमाणन और iBeta Level 1 प्रेजेंटेशन अटैक डिटेक्शन परीक्षण हैं।^[23] मूल्यों के लिए मूल्य निर्धारण देखें।

अक्सर पूछे जाने वाले प्रश्न

स्रोत

1. Regulation (EU) No 910/2014, 18 अक्टूबर 2024 का समेकित पाठ, EUR-Lex.
2. Commission Implementing Regulation (EU) 2025/848, wallet-relying parties का पंजीकरण, EUR-Lex.
3. Commission Implementing Regulation (EU) 2026/1730, दिनांक 15 जुलाई 2026, EUR-Lex.
4. Commission Implementing Regulation (EU) 2024/2982, प्रोटोकॉल और इंटरफ़ेस, EUR-Lex.
5. Commission Implementing Regulation (EU) 2026/1731, दिनांक 15 जुलाई 2026, EUR-Lex.
6. Architecture and Reference Framework v3.0.0, European Commission, जुलाई 2026.
7. ARF v3.0.0, Annex 2, विषय के अनुसार उच्च-स्तरीय आवश्यकताएं, European Commission.
8. Technical Specification 5, relying party पंजीकरण के प्रारूप और API, European Commission.
9. Regulation (EU) 2024/1624 (AMLR), EUR-Lex.
10. Regulation (EU) 2016/679 (GDPR), EUR-Lex.
11. Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex.
12. OpenID4VP और OpenID4VCI अनुरूपता परीक्षण पूरे हो गए हैं और स्व-प्रमाणन के लिए खुले हैं, OpenID Foundation, 7 अगस्त 2026.
13. Functional Conformance Assessment Framework, EUDI Wallet परियोजना.
14. EUDI Wallet Reference Implementation दस्तावेज़ीकरण, European Commission.
15. EUDI verifier endpoint रिपॉजिटरी, Apache License 2.0.
16. ARF v3.0.0, Annex 5, डेटा साझाकरण परिदृश्यों के लिए डिज़ाइन गाइड, European Commission.
17. EUDI Wallet, Didit समाधान पेज.
18. डिजिटल ID wallets, Didit दस्तावेज़ीकरण.
19. Workflow builder, Didit दस्तावेज़ीकरण.
20. Webhooks, Didit दस्तावेज़ीकरण.
21. डेटा प्रतिधारण, Didit दस्तावेज़ीकरण.
22. सुरक्षा और अनुपालन, Didit दस्तावेज़ीकरण.
23. प्रमाणन, Didit दस्तावेज़ीकरण.

आज आप जो रास्ता चुनते हैं, उसे वेंडर बदलने, राष्ट्रीय वॉलेट की देरी और रिटेंशन ऑडिट के बाद भी टिके रहना चाहिए। रोलआउट पर नज़र रखें और देखें कि Didit स्वीकृति को कैसे देखता है, EUDI Wallet समाधान पेज पर।