OpenID4VP वेरिफ़ायर गाइड: EUDI वॉलेट स्वीकार करना

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

OpenID4VP वह तरीका है जिससे कोई वेबसाइट या ऐप किसी वॉलेट से किसी व्यक्ति के बारे में कुछ साबित करने को कहता है, जैसे नाम या जन्म तिथि। सत्यापनकर्ता बताता है कि उसे कौन से क्रेडेंशियल और दावे (claims) चाहिए, उपयोगकर्ता वॉलेट में स्वीकृति देता है, और वॉलेट एक प्रस्तुति लौटाता है जिसकी जाँच सत्यापनकर्ता क्रिप्टोग्राफ़िक रूप से करता है। स्पेसिफ़िकेशन के अपने शब्दों में, यह "क्रेडेंशियल का अनुरोध करने और उन्हें प्रस्तुत करने के लिए एक प्रोटोकॉल परिभाषित करता है"।^[1]

यह गाइड उन डेवलपर्स के लिए है जो EUDI वॉलेट के लिए OpenID4VP सत्यापनकर्ता बना रहे हैं: रिक्वेस्ट ऑब्जेक्ट, DCQL, रिस्पॉन्स मोड, डिवाइस फ़्लो, SD-JWT VC और mdoc की जाँच, EU कानून में HAIP नियम, आम गलतियाँ और परीक्षण कहाँ करें।

OpenID4VP सरल शब्दों में

OpenID4VP, OAuth 2.0 ऑथराइज़ेशन रिक्वेस्ट की संरचना को दोबारा उपयोग करता है। सत्यापनकर्ता रिस्पॉन्स टाइप vp_token माँगता है, और सफल रिस्पॉन्स में प्रस्तुतियाँ ले जाने वाला vp_token पैरामीटर शामिल होना अनिवार्य है।^[1] बदलने के लिए कोई कोड या एक्सेस टोकन नहीं होता: डेटा रिस्पॉन्स में ही आता है।

वॉलेट रिलाइंग पार्टी (relying party) को प्रमाणित करता है, जाँचता है कि वह अपने पंजीकरण से अधिक कुछ नहीं माँग रही, उपयोगकर्ता की स्वीकृति लेता है और प्रस्तुति पर हस्ताक्षर करता है। इसके बाद रिलाइंग पार्टी जारीकर्ता के हस्ताक्षर, निरस्तीकरण स्थिति और डिवाइस बाइंडिंग का सत्यापन करती है।^[3] व्यक्ति पहचान डेटा (PID) दो फ़ॉर्मेट में जारी किया जाता है, SD-JWT VC और ISO/IEC mdoc, और दोनों salted hash का उपयोग करते हैं ताकि उपयोगकर्ता कुछ विशेषताएँ साझा कर सके और बाकी छिपा सके।^[5][3]

1. 10 जुलाई 2025अंतिम विनिर्देशOpenID4VP 1.0 स्वीकृत।
2. 22 जुलाई 2026प्रकाशितCIR 2026/1731 (15 जुलाई 2026 को अपनाया गया) आधिकारिक राजपत्र (Official Journal) में।
3. 23 जुलाई 2026ARF v3.0.0वर्तमान आर्किटेक्चर रिलीज़।
4. 24 दिसंबर 2026वॉलेटप्रत्येक सदस्य राज्य में कम से कम एक।
5. 24 दिसंबर 2027स्वीकृतिविनियमित निजी रिलाइंग पार्टियाँ।

अंतिम विनिर्देश से निजी क्षेत्र की स्वीकृति तिथि तक।^[2][3][4][5]

OpenID4VP सत्यापनकर्ता का आदान-प्रदान कैसे काम करता है

OpenID4VP रिस्पॉन्स मोड direct_post के लिए एक संदर्भ डिज़ाइन प्रकाशित करता है, जिसमें वॉलेट रिस्पॉन्स को ब्राउज़र के माध्यम से भेजने के बजाय सर्वर एंडपॉइंट पर पोस्ट करता है।^[1]

OpenID4VP 1.0, अनुभाग 13.3 का direct_post संदर्भ डिज़ाइन, सरलीकृत रूप में।^[1]

• हर अनुरोध के लिए "कम से कम 16 नए, क्रिप्टोग्राफ़िक रूप से रैंडम बाइट्स" का nonce बनाएँ।
• response endpoint से मिला request-id वॉलेट को state के रूप में भेजें।
• वॉलेट के post करने पर नए response_code के साथ एक redirect URI लौटाएँ।
• transaction-id और उस code से VP Token प्राप्त करें, फिर nonce की जाँच करें।

response_code session fixation को रोकता है, जिसमें हमलावर आपका अनुरोध किसी पीड़ित के वॉलेट तक पहुँचा देता है। विनिर्देश में कहा गया है कि अलग-अलग डिवाइसों के बीच यह मदद नहीं करता। वहाँ के लिए यह अतिरिक्त तंत्रों की सिफ़ारिश करता है।^[1]

OpenID4VP अनुरोध ऑब्जेक्ट और क्लाइंट पहचानकर्ता

client_id एक Client Identifier Prefix से शुरू होता है। यह वॉलेट को बताता है कि सत्यापनकर्ता को कैसे प्रमाणित करना है।^[1] बड़े अनुरोध संदर्भ द्वारा भेजे जाते हैं: वॉलेट हस्ताक्षरित अनुरोध ऑब्जेक्ट को request_uri से प्राप्त करता है। QR कोड के लिए विनिर्देश request_uri के साथ direct_post की सिफ़ारिश करता है, क्योंकि अनुरोध "शायद QR कोड में न समाए"।^[1]

Client Identifier Prefixes, OpenID4VP 1.0 खंड 5.9.^[1]

EUDI सत्यापनकर्ताओं के लिए prefix EU कानून तय करता है: leaf प्रमाणपत्र "x509_hash Client Identifier Prefix के साथ उपयोग के लिए ETSI TS 119 475 में निर्दिष्ट RP access certificate होगा", और verifier_info के एक तत्व में "registration certificate शामिल होगा"।^[5]

DCQL क्वेरी: वही माँगें जो आपने पंजीकृत किया है

Digital Credentials Query Language (DCQL) वह JSON क्वेरी है जो उन क्रेडेंशियल और claims के नाम बताती है जो आप चाहते हैं। इसमें एक अनिवार्य credentials array और एक वैकल्पिक credential_sets array होता है। हर credential query में एक id, एक format और एक meta object होना चाहिए।^[1] विनिर्देश का SD-JWT VC उदाहरण:^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

mdoc के लिए format mso_mdoc होता है और meta में एक doctype_value होता है।^[1] PID के लिए उसका type और claim नाम डालें। PID के अनिवार्य attributes हैं: कुलनाम, प्रथम नाम, जन्म तिथि, जन्म स्थान और राष्ट्रीयता।^[7]

• require_cryptographic_holder_binding डिफ़ॉल्ट रूप से true होता है। इसे ऐसे ही रखें: इससे वॉलेट key binding proof लौटाता है।^[1]
• trusted_authorities केवल यह फ़िल्टर करता है कि वॉलेट क्या पेश करता है। सत्यापनकर्ताओं को "स्वयं यह सत्यापित करना होगा कि प्राप्त presentation का जारीकर्ता विश्वसनीय है"।^[1]
• रिलाइंग पार्टियाँ (relying parties) उपयोगकर्ताओं से अपने पंजीकृत डेटा "के अलावा कोई अन्य डेटा देने का अनुरोध नहीं करेंगे", और वॉलेट इसकी जाँच करता है।^[4][3]

OpenID4VP रिस्पॉन्स मोड

रिस्पॉन्स मोड तय करता है कि VP Token वापस कैसे पहुँचता है। vp_token के लिए डिफ़ॉल्ट fragment है, यानी redirect URI के fragment में।^[1]

OpenID4VP 1.0 में रिस्पॉन्स मोड।^[1]

direct_post के साथ response_uri आवश्यक है और redirect_uri मौजूद नहीं होना चाहिए, अन्यथा वॉलेट invalid_request लौटाता है।^[1] उदाहरण के लिए, मोल्दोवा का EVO Wallet अपने दस्तावेज़ों में ये बातें बताता है: एक ही डिवाइस वाले फ्लो में direct_post.jwt के साथ OpenID4VP 1.0, OpenID4VC HAIP 1.0 के अनुसार प्रोफ़ाइल किया गया ISO/IEC 18013-5 mdoc, और रद्दीकरण (revocation) के लिए IETF Token Status List।^[11]

एक ही डिवाइस, क्रॉस-डिवाइस और Digital Credentials API

ARF समर्थित रिमोट संयोजनों की सूची देता है। पहला, रीडायरेक्ट और कस्टम URI स्कीम पर आधारित ट्रांसमिशन तंत्र के साथ OpenID4VP। दूसरा, W3C Digital Credentials API के साथ OpenID4VP या ISO/IEC 18013-7। तीसरा, वैकल्पिक रूप से, रीडायरेक्ट और कस्टम URI स्कीम के साथ ISO/IEC 18013-7।^[3]

वॉलेट को OpenID4VP अनुरोध मिलने के तीन तरीके।^[3][1][10]

ARF कहता है कि कस्टम URI स्कीम "क्रॉस-डिवाइस फ्लो के लिए अनुशंसित नहीं" हैं। वह विकल्प के रूप में Digital Credentials API का नाम लेता है।^[3] इस API के ज़रिए वॉलेट को सत्यापनकर्ता का वह ऑरिजिन पता चलता है जिसे ब्राउज़र ने प्रमाणित किया है, "जो फ़िशिंग प्रतिरोध के लिए महत्वपूर्ण है"।^[1] W3C विनिर्देश अभी भी ड्राफ़्ट है।^[9] फ़ोन पर उपयोगकर्ता को यह दिखता है:

SD-JWT VC प्रस्तुति का सत्यापन, चरण दर चरण

SD-JWT VC प्रस्तुति में जारीकर्ता द्वारा हस्ताक्षरित JWT, उपयोगकर्ता द्वारा प्रकट किए गए डिस्क्लोज़र और एक Key Binding JWT होते हैं। सत्यापनकर्ता को "प्रत्येक व्यक्तिगत Verifiable Presentation को अनिवार्य रूप से सत्यापित करना होगा" और गलत nonce वाली हर प्रस्तुति को अस्वीकार करना होगा।^[1]

एक SD-JWT VC प्रस्तुति पर सत्यापनकर्ता की जाँचें।^[1][3]

जारीकर्ता के हस्ताक्षर। ARF इसे रिलाइंग पार्टी की जाँचों में सबसे पहले सूचीबद्ध करता है। ट्रस्ट एंकर Trusted Lists (ETSI TS 119 612) और Lists of Trusted Entities (ETSI TS 119 602) से आते हैं।^[3]

डिस्क्लोज़र। हस्ताक्षरित पेलोड में डाइजेस्ट की एक _sd array होती है; हर डिस्क्लोज़र एक salt, एक claim नाम और एक मान होता है, जैसे ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]।^[1] हर डिस्क्लोज़र का हैश निकालें और उसका डाइजेस्ट खोजें। मेल न मिलने का अर्थ है कि जारीकर्ता ने उस पर हस्ताक्षर नहीं किए।

Key Binding JWT. जब होल्डर बाइंडिंग आवश्यक हो, तो वॉलेट को "अनिवार्य रूप से Key Binding JWT के साथ एक SD-JWT लौटाना होगा"। इसका nonce आपके अनुरोध के nonce के बराबर होना चाहिए और इसका aud आपके Client Identifier के बराबर होना चाहिए, या Digital Credentials API के माध्यम से origin: उपसर्ग वाले आपके origin के बराबर।^[1] विनिर्देश का उदाहरण:

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

निरस्तीकरण। रिलाइंग पार्टी सत्यापित करती है कि प्रदाता ने "PID या एटेस्टेशन को निरस्त नहीं किया है"।^[3] उदाहरण के लिए, मोल्दोवा का EVO Wallet इसके लिए एक IETF Token Status List का दस्तावेज़ीकरण करता है।^[11]

ISO/IEC 18013-7 के माध्यम से mdoc प्रस्तुतियां, संक्षेप में

mdoc के लिए, VP Token में ISO/IEC 18013-5 का base64url-एन्कोडेड DeviceResponse होता है, जो "SessionTranscript पर एक हस्ताक्षर या MAC रखता है", और इसमें एक OpenID4VP हैंडओवर संरचना भी शामिल होती है।^[1] यह हैंडओवर mdoc को आपके अनुरोध से उसी तरह बांधता है, जैसे nonce और audience किसी SD-JWT VC को बांधते हैं।

हमारी SD-JWT VC बनाम mdoc तुलना बताती है कि कौन सा फॉर्मेट कब उपयुक्त है।

HAIP प्रोफाइल EUDI सत्यापनकर्ताओं के लिए क्या जोड़ता है

High Assurance Interoperability Profile (HAIP) OpenID4VP के विकल्पों को सीमित करता है। ARF पहले से ही जारी करने (issuance) के लिए इसकी अपेक्षा करता है और कहता है कि इसका उपयोग "इंटरऑपरेबिलिटी सुनिश्चित करने के लिए आवश्यक है"।^[3] प्रस्तुति के लिए, CIR 2026/1731 एक "OpenID4VC-HAIP profile" और एक "ISO/IEC-mdoc profile" निर्धारित करता है।^[5]

पंजीकरण प्रमाणपत्र "रिलाइंग पार्टी के इच्छित उपयोग का वर्णन करता है और उन एट्रिब्यूट्स को इंगित करता है" जिनका उसने पंजीकरण कराया है, और पंजीकरण विनियमन 24 दिसंबर 2026 से लागू होता है।^[6] 11 अगस्त 2028 की तारीख केवल उस प्रमाणपत्र की वॉलेट-स्तर पर जांच से संबंधित है, पंजीकरण से नहीं।^[5] जर्मनी इसे संक्षेप में इस तरह बताता है: एक संगठन "संगठन और उपयोग के मामले के लिए एक्सेस और पंजीकरण प्रमाणपत्र प्राप्त करता है"।^[12] हमारी EUDI वॉलेट रिलाइंग पार्टी गाइड पंजीकरण को विस्तार से बताती है।

OpenID4VP सत्यापनकर्ता बनाते समय होने वाली आम गलतियां

वॉलेट स्वैच्छिक भी है: जो लोग इसका उपयोग नहीं करते, उनके लिए पहुँच "किसी भी तरह से प्रतिबंधित या नुकसानदेह नहीं बनाई जाएगी", इसलिए आपका सत्यापनकर्ता एक दूसरे रास्ते के साथ चलता है।^[4]

परीक्षण संसाधन

राष्ट्रीय वॉलेट के साथ परीक्षण करने से पहले रेफ़रेंस सॉफ़्टवेयर और अनुरूपता परीक्षणों से शुरुआत करें।

• conformance.eudi.dev पर अनुरूपता परीक्षण चलाएँ।^[3]
• docs.eudi.dev पर रेफ़रेंस इम्प्लीमेंटेशन के दस्तावेज़ पढ़ें। ये दस्तावेज़ हैं, परीक्षण नहीं।^[3]
• नेशनल बैंक ऑफ मोल्दोवा के डेमो सत्यापनकर्ता और उसके सोर्स कोड का अध्ययन करें।^[13]
• ब्राउज़र वाले रास्ते पर निर्भर होने से पहले Digital Credentials API का ड्राफ़्ट देखें।^[9]

अपनी परीक्षण योजना की तारीखों के लिए 2026 और 2027 के लिए EUDI वॉलेट की समय-सीमाएँ देखें।

EUDI वॉलेट सत्यापन में Didit कैसे मदद करता है

Didit पर EUDI वॉलेट स्वीकृति जल्द आ रही है: यह हमारे रोडमैप पर है, EUDI वॉलेट की समय-सारिणी के अनुरूप, उसी वर्कफ़्लो में जिसका आप आज उपयोग करते हैं। इस बीच, आप अभी लोगों का दूर से सत्यापन कर सकते हैं।

• पाँच राष्ट्रीय eID आज Didit में डिजिटल आईडी वॉलेट के ज़रिए चलती हैं: MitID, BankID Sweden, Finnish Trust Network, Smart-ID और Mobile-ID। eID सत्यापन देखें।
• अगर किसी व्यक्ति के पास eID नहीं है, तो फ़्लो दस्तावेज़ सत्यापन पर चला जाता है, जिसमें NFC चिप रीडिंग, लाइवनेस और फ़ेस मैच शामिल हैं। इन्हें हर देश के लिए अलग से कॉन्फ़िगर किया जाता है। एक पूरी KYC जाँच की लागत $0.33 है।
• AML स्क्रीनिंग उसी फ़्लो में $0.20 पर चलती है।

रिलाइंग पार्टी के रूप में आपके दायित्व आपके पास ही रहते हैं। वॉलेट दस्तावेज़ दिखाते हैं कि हर देश के लिए eID कैसे चालू की जाती हैं।

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

स्रोत

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, अंतिम विनिर्देश।
2. OpenID for Verifiable Presentations 1.0 का अंतिम विनिर्देश स्वीकृत, OpenID Foundation, 10 जुलाई 2025।
3. Architecture and Reference Framework v3.0.0, GitHub पर eu-digital-identity-wallet, 23 जुलाई 2026 की रिलीज़।
4. विनियमन (EU) 2024/1183 (eIDAS 2), EUR-Lex, 30 अप्रैल 2024 का आधिकारिक राजपत्र।
5. आयोग कार्यान्वयन विनियमन (EU) 2026/1731, EUR-Lex, 22 जुलाई 2026 का आधिकारिक राजपत्र।
6. वॉलेट-रिलाइंग पार्टियों के पंजीकरण पर आयोग कार्यान्वयन विनियमन (EU) 2025/848, EUR-Lex, 7 मई 2025 का आधिकारिक राजपत्र।
7. व्यक्ति पहचान डेटा पर आयोग कार्यान्वयन विनियमन (EU) 2024/2977, EUR-Lex, 4 दिसंबर 2024 का आधिकारिक राजपत्र।
8. ISO/IEC 18013-7, ISO मानक पृष्ठ।
9. Digital Credentials, W3C मसौदा।
10. Digital Credentials API जारी किया गया, Chrome for Developers।
11. EVO Wallet डेवलपर गाइड, मोल्दोवा सरकार, egov4dev।
12. EUDI वॉलेट FAQ, eudi-wallet.gov.de।
13. BNM डेमो सत्यापनकर्ता, मोल्दोवा सरकार, egov4dev।

OpenID4VP, EUDI वॉलेट का वह हिस्सा है जिसके साथ डेवलपर सबसे अधिक काम करते हैं। यह इतना स्थिर है कि इस पर निर्माण किया जा सके। Didit वॉलेट स्वीकार करने को कैसे देखता है, यह EUDI वॉलेट समाधान पृष्ठ पर देखें, और व्यापक तस्वीर हमारे eIDAS 2 अवलोकन में देखें।