अगर आपका ऐप आज यूज़र्स से उनके पासपोर्ट या ID कार्ड की फ़ोटो माँगता है, तो आपने शायद सुना होगा कि EU डिजिटल आइडेंटिटी वॉलेट (EUDI Wallet) "2026 के अंत में" आ रहे हैं। तारीख़ असली है, और सटीक है: 24 दिसंबर 2026। पर यह डेडलाइन सदस्य देशों के लिए है, आपके लिए नहीं, और यह दस्तावेज़ स्कैन को बंद नहीं करती।

यह पोस्ट तीन काम करती है। यह दिखाती है कि तारीख़ कहाँ से आती है, पूरे हिसाब के साथ। यह नियमों की एट्रिब्यूट तालिकाओं के आधार पर बताती है कि वॉलेट असल में क्या सौंपता है। और यह एक ऐसे डिज़ाइन की रूपरेखा देती है जो यूज़र के पास वॉलेट होने पर वॉलेट स्वीकार करता है और न होने पर दस्तावेज़ स्कैन पर लौट आता है। इसे doc.cheap ने लिखा है, जो एक पासपोर्ट और ID कार्ड OCR API है, इसलिए प्रोडक्ट वाले हिस्से यह ध्यान में रखकर पढ़ें। doc.cheap दस्तावेज़ों की इमेज पढ़ता है; वह वॉलेट नहीं पढ़ता।

24 दिसंबर 2026 कहाँ से आता है

यह दायित्व Reg. (EU) No 910/2014 का अनुच्छेद 5a(1) है, जिसे eIDAS संशोधन Reg. (EU) 2024/1183 ने जोड़ा। इसके अनुसार हर सदस्य देश "इस अनुच्छेद के पैराग्राफ़ 23 और अनुच्छेद 5c(6) में उल्लिखित इम्प्लीमेंटिंग एक्ट्स के लागू होने की तारीख़ से 24 महीनों के भीतर कम से कम एक यूरोपियन डिजिटल आइडेंटिटी वॉलेट उपलब्ध कराएगा"।

यानी घड़ी ख़ुद eIDAS संशोधन से शुरू नहीं होती। वह कमीशन के इम्प्लीमेंटिंग एक्ट्स (कार्यान्वयन अधिनियम) से शुरू होती है। अनुच्छेद 5a(23) वाले एक्ट्स, 28 नवंबर 2024 की तारीख़ वाले कमीशन के चार इम्प्लीमेंटिंग एक्ट्स हैं, जिनमें वॉलेट की इंटीग्रिटी और मुख्य फ़ंक्शनैलिटी पर Implementing Reg. (EU) 2024/2979 भी शामिल है। यह 4 दिसंबर 2024 को आधिकारिक जर्नल (OJ L, 2024/2979) में प्रकाशित हुआ। इसका अनुच्छेद 15 कहता है कि यह "यूरोपियन यूनियन के आधिकारिक जर्नल में प्रकाशन के बाद बीसवें दिन लागू होगा"।

हिसाब:

चरण तारीख़
आधिकारिक जर्नल में प्रकाशन 4 दिसंबर 2024
प्रकाशन के बाद पहला दिन 5 दिसंबर 2024
प्रकाशन के बाद बीसवाँ दिन: लागू होना 24 दिसंबर 2024
जोड़ें 24 महीने (अनुच्छेद 5a(1)): वॉलेट की डेडलाइन 24 दिसंबर 2026
जोड़ें 36 महीने (अनुच्छेद 5f(2)): कुछ प्राइवेट रिलाइंग पार्टियों को वॉलेट स्वीकार करने होंगे 24 दिसंबर 2027

"बाद बीसवाँ दिन" प्रकाशन के अगले दिन से गिना जाता है, इसलिए 4 दिसंबर में 20 दिन जोड़ने पर 24 तारीख़ आती है, 23 नहीं। इसी एक्ट की गिनती से तालिका की दूसरी तारीख़ भी तय होती है, और ज़्यादातर प्रोडक्ट टीमों के लिए असल में वही तारीख़ मायने रखती है (उस पर नीचे और बात है)।

वॉलेट क्या सौंपता है

वॉलेट पासपोर्ट की तस्वीर नहीं भेजता। वह साइन किया हुआ डेटा पेश करता है। किसी प्राकृतिक व्यक्ति का डेटा सेट Implementing Reg. (EU) 2024/2977 के एनेक्स में तय है: "पर्सन आइडेंटिफ़िकेशन डेटा" (PID)। एनेक्स कहता है कि PID दो फ़ॉर्मैट में जारी होता है: ISO/IEC 18013-5:2021 और W3C का "Verifiable Credentials Data Model 1.1"।

ये रहे एट्रिब्यूट, और टेक्स्ट हर एक को जो उपस्थिति देता है वह (एनेक्स की तालिका 1, 2 और 5, जैसी 4 दिसंबर 2024 को प्रकाशित हुईं)। आख़िरी कॉलम doc.cheap के स्कैन रिस्पॉन्स का सबसे नज़दीकी फ़ील्ड है, ताकि आप देख सकें कि दोनों दुनिया कहाँ मेल खाती हैं और कहाँ नहीं।

PID एट्रिब्यूट उपस्थिति दस्तावेज़ स्कैन में सबसे नज़दीकी फ़ील्ड
family_name अनिवार्य holder.surname
given_name अनिवार्य holder.given_names
birth_date अनिवार्य holder.birth_date (ISO 8601)
birth_place अनिवार्य fields[] में एक birth_place एंट्री, जब दस्तावेज़ पर यह छपा हो
nationality अनिवार्य (alpha-2, एक या ज़्यादा) holder.nationality (alpha-3, एक)
resident_address, resident_country, resident_state, resident_city, resident_postal_code, resident_street, resident_house_number वैकल्पिक पासपोर्ट के डेटा पेज पर कुछ नहीं
personal_administrative_number वैकल्पिक यह वही चीज़ नहीं है; fields[] में दस्तावेज़ पर छपा personal_number हो सकता है
portrait वैकल्पिक images.main_photo
family_name_birth, given_name_birth वैकल्पिक कोई क्यूरेटेड फ़ील्ड नहीं
sex वैकल्पिक (कोड 0, 1, 2, 3, 4, 5, 6, 9) holder.sex (M, F, X)
email_address, mobile_phone_number वैकल्पिक दस्तावेज़ पर नहीं होते
expiry_date (मेटाडेटा) अनिवार्य document.expiry_date, पर यह दस्तावेज़ की है, PID की नहीं
issuing_authority (मेटाडेटा) अनिवार्य fields[] में एक authority एंट्री, जब छपी हो
issuing_country (मेटाडेटा) अनिवार्य (alpha-2) document.issuing_state (alpha-3)
document_number (मेटाडेटा) वैकल्पिक यह वही चीज़ नहीं है: PID का नंबर PID प्रोवाइडर देता है, document.number पासपोर्ट का नंबर है
issuing_jurisdiction, location_status (मेटाडेटा) वैकल्पिक कुछ नहीं

मैपिंग कोड लिखते समय इस तालिका की तीन बातें मायने रखती हैं।

  • देश कोड अलग हैं। PID ISO 3166-1 alpha-2 (DE) इस्तेमाल करता है। पासपोर्ट और मशीन-रीडेबल ज़ोन (MRZ) alpha-3 (DEU) इस्तेमाल करते हैं। अंदर एक ही रूप रखें और किनारे पर कन्वर्ट करें।
  • "अनिवार्य" का मतलब "हमेशा ज्ञात" नहीं है। तालिका 1 के नीचे टेक्स्ट जोड़ता है: "जहाँ किसी एट्रिब्यूट का मान व्यक्ति के लिए ज्ञात न हो या पर्सन आइडेंटिफ़िकेशन डेटासेट के हिस्से के रूप में किसी और तरह जारी न किया जा सके, वहाँ सदस्य देश उसकी जगह स्थिति के अनुरूप एट्रिब्यूट मान का उपयोग करेंगे।" ग़ायब कीज़ की नहीं, प्लेसहोल्डर मानों की उम्मीद रखें।
  • व्यक्ति से जुड़े सिर्फ़ पाँच एट्रिब्यूट अनिवार्य हैं। पता, पोर्ट्रेट, लिंग और जन्म के समय के नाम, सब वैकल्पिक हैं। अगर आपके फ़्लो को इनमें से किसी की ज़रूरत है, तो हो सकता है किसी यूज़र का वॉलेट उसे रखता ही न हो।

दस्तावेज़ के साथ कौन आता रहेगा

डेडलाइन हर सदस्य देश को वॉलेट उपलब्ध कराने के लिए बाध्य करती है। यह किसी को उसे इस्तेमाल करने के लिए बाध्य नहीं करती। अनुच्छेद 5a(15) साफ़ कहता है: "यूरोपियन डिजिटल आइडेंटिटी वॉलेट का उपयोग स्वैच्छिक होगा।" और आगे: "पब्लिक और प्राइवेट सेवाओं तक अन्य मौजूदा पहचान और प्रमाणीकरण साधनों से पहुँचना संभव बना रहेगा।"

इसलिए 24 दिसंबर 2026 के बाद भी आपको ये दिखते रहेंगे:

  • EU के बाहर के यात्री और ग्राहक। रिसाइटल्स (प्रस्तावना के खंड) वॉलेट को "यूनियन के नागरिकों, यूनियन में रहने वालों या कानूनी व्यक्तियों की कानूनी पहचान" से जोड़ते हैं। किसी दूसरे देश के पासपोर्ट वाले विज़िटर के पास दिखाने को कोई EU वॉलेट नहीं होता।
  • वे लोग जिन्होंने वॉलेट इंस्टॉल नहीं किया, या नहीं कर सकते, या करना नहीं चाहते। टेक्स्ट इस चुनाव की रक्षा करता है।
  • ऐसे फ़्लो जिन्हें ख़ुद दस्तावेज़ चाहिए। कुछ प्रोसेस को व्यक्ति के बारे में किसी अटेस्टेशन की जगह दस्तावेज़ की इमेज, दस्तावेज़ नंबर या भौतिक दस्तावेज़ का मशीन-रीडेबल ज़ोन चाहिए होता है। वॉलेट के PID में अपना document_number होता है, जो PID प्रोवाइडर देता है, और वह पासपोर्ट का नंबर नहीं है।
  • किसी देश का वॉलेट लाइव होने से पहले का समय। 24 दिसंबर 2026 क़ानूनी डेडलाइन है। हर राष्ट्रीय वॉलेट असल में यूज़र्स तक कब पहुँचेगा, यह अलग सवाल है, और किसी एक देश के लिए भरोसेमंद जवाब सिर्फ़ उसी देश की अपनी घोषणा या कमीशन की घोषणा है।

दोनों को स्वीकार करने वाला डिज़ाइन

इन सब के बाद टिकने वाला ढाँचा सीधा है: यूज़र के पास वॉलेट हो तो वॉलेट प्रेज़ेंटेशन माँगें, और न हो तो दस्तावेज़ स्कैन पर लौट आएँ। दोनों रास्ते एक ही इंटरनल रिकॉर्ड पर ख़त्म होते हैं।

user starts verification
        |
        v
  offers a wallet? --yes--> wallet presentation --> verify signature --> map PID
        |                                                               |
        no                                                              v
        |                                                      internal identity
        v                                                          record
  document photo --> POST /v1/scans --> map scan fields ----------------^

कुछ नियम दोनों रास्तों को आपस में बदलने लायक बनाते हैं:

  1. दोनों को एक रिकॉर्ड में मैप करें, अपने फ़ील्ड नामों के साथ। मैपिंग के लिए ऊपर की तालिका इस्तेमाल करें।
  2. स्रोत रखें। दर्ज करें कि रिकॉर्ड वॉलेट से आया या स्कैन से। दोनों अलग-अलग सबूत रखते हैं, और रिव्यू करने वाला जानना चाहेगा कि कौन-सा।
  3. null को ईमानदार मानें। doc.cheap के रिस्पॉन्स में हर key हमेशा मौजूद रहती है और अज्ञात मान null होता है। वॉलेट उसकी जगह प्लेसहोल्डर भेज सकता है। दोनों को एक ही नियम पर नॉर्मलाइज़ करें।
  4. उतना ही स्टोर करें जितना फ़्लो को चाहिए। स्कैन इस तरह चलाया जा सकता है कि API की तरफ़ कुछ भी लिखा न जाए (नीचे देखें)।

ये रहा सादे fetch से फ़ॉलबैक कॉल। पब्लिक sandbox key sk_sandbox_public डॉक्स में छपी है और इसके लिए साइनअप की ज़रूरत नहीं; इस पर हर क्लाइंट एड्रेस के हिसाब से रेट लिमिट है।

import { readFileSync } from "node:fs";
import { randomUUID } from "node:crypto";

async function scanDocument(path, apiKey = "sk_sandbox_public") {
  const response = await fetch("https://api.doc.cheap/v1/scans", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": randomUUID(), // रीट्राई पहला नतीजा लौटाता है
    },
    body: JSON.stringify({
      image: readFileSync(path).toString("base64"),
      options: { retain_hours: 0, return_portrait: false }, // कुछ भी स्टोर नहीं होता
    }),
  });
  if (!response.ok) throw new Error(`scan failed: HTTP ${response.status}`);
  return response.json();
}

// स्कैन को उसी रिकॉर्ड में मैप करें जिसे वॉलेट प्रेज़ेंटेशन भरता।
function fromScan(scan) {
  if (scan.meta.status !== "recognized") return null;
  const field = (name) => scan.fields.find((f) => f.id === `${name}@0`)?.value ?? null;
  return {
    source: "document_scan",
    family_name: scan.holder?.surname ?? null,
    given_name: scan.holder?.given_names ?? null,
    birth_date: scan.holder?.birth_date ?? null,
    birth_place: field("birth_place"),
    nationality_alpha3: scan.holder?.nationality ?? null,
    issuing_country_alpha3: scan.document?.issuing_state ?? null,
    document_number: scan.document?.number ?? null,
    mrz_status: scan.mrz.status, // "passed", "failed" या "absent"
  };
}

meta.status पाँच स्ट्रिंग्स में से एक है: recognized, no_document_found, unreadable, unsupported_document या rejected। सिर्फ़ पहली से रिकॉर्ड भरना चाहिए; बाक़ी पर यूज़र को दोबारा फ़ोटो लेने के लिए वापस भेजना चाहिए। पेड key पर बैलेंस तभी कटता है जब स्कैन बिल करने लायक हो।

हमने 24 सितंबर 2026 को 21:17 UTC पर sk_sandbox_public के साथ इस तरह की एक कॉल चलाई, प्रोडक्ट के अपने टेस्ट दस्तावेज़ से, जो एक पासपोर्ट है। रिस्पॉन्स HTTP 200 के साथ आया। नीचे दस्तावेज़ का हर मान छिपाया (मास्क किया) गया है, और fields, images और mrz.lines छोटे किए गए हैं:

{
  "meta": {
    "schema_version": "1.0",
    "id": "<SCAN_ID>",
    "status": "recognized",
    "billed": true,
    "confidence": "medium",
    "timing": { "upload_ms": 255, "processing_ms": 409, "total_ms": 678 },
    "created_at": "<RUN_TIMESTAMP>",
    "reference": null
  },
  "document": {
    "kind": "passport", "country": "<ISO3>", "country_name": "<COUNTRY>",
    "issuing_state": "<ISO3>", "number": "<DOCUMENT_NUMBER>", "series": null,
    "issue_date": "<DATE>", "expiry_date": "<DATE>", "is_expired": false, "days_remaining": "<N>"
  },
  "holder": {
    "given_names": "<GIVEN_NAMES>", "surname": "<SURNAME>", "full_name": "<FULL_NAME>",
    "birth_date": "<DATE>", "sex": "<SEX>", "nationality": "<ISO3>"
  },
  "mrz": { "status": "passed", "reason": null, "lines": ["<LINE_1>", "<LINE_2>"], "text": "<MRZ>" },
  "quality": { "overall": "pass" },
  "authenticity": { "overall": "not_checked", "checks": [] }
}

वहाँ billed: true का मतलब है कि स्कैन बिल करने लायक था और sandbox के मुफ़्त कोटे में गिना गया; sandbox key से ख़ुद कभी पैसा नहीं कटता। उस रन के fields ऐरे में birth_place, authority और personal_number एंट्रीज़ थीं, और ऊपर की तालिका उन PID एट्रिब्यूट्स के लिए यहीं इशारा करती है। पासपोर्ट का डेटा पेज अपना MRZ TD3 लेआउट में दो लाइनों में रखता है; TD1, TD2 और TD3 फ़ॉर्मैट वाला पेज इन लेआउट्स को साथ-साथ दिखाता है।

authenticity.overall: "not_checked" पर ध्यान दें। ऐसा स्कैन रिकग्निशन है: यह वह पढ़ता है जो छपा है और MRZ के चेक डिजिट जाँचता है। यह जालसाज़ी की पहचान नहीं है, और यह साइन किए हुए वॉलेट प्रेज़ेंटेशन जितना भरोसा नहीं देता। अगर आपके प्रोसेस को स्कैन वाले रास्ते पर ज़्यादा ऊँचा एश्योरेंस लेवल चाहिए, तो वह आपके फ़्लो में कहीं और से आना होगा। अगर आप फ़ॉलबैक के लिए प्रोवाइडर चुन रहे हैं, तो हमारी पासपोर्ट OCR API तुलना विकल्पों को सामने रखती है, जिनमें वे भी शामिल हैं जो रिकग्निशन से ज़्यादा करते हैं।

आगे किस पर नज़र रखें

  • 24 दिसंबर 2026 – वॉलेट की डेडलाइन। अनुच्छेद 5a(1), Reg. (EU) 2024/1183, इम्प्लीमेंटिंग एक्ट्स के लागू होने से गिना गया, जैसा ऊपर दिखाया है।
  • 24 दिसंबर 2027 – प्राइवेट रिलाइंग पार्टियाँ। अनुच्छेद 5f(2) कहता है कि जिन प्राइवेट रिलाइंग पार्टियों को क़ानून या अनुबंध के तहत ऑनलाइन पहचान के लिए स्ट्रॉन्ग यूज़र ऑथेंटिकेशन इस्तेमाल करना होता है, वे "अनुच्छेद 5a(23) और अनुच्छेद 5c(6) में उल्लिखित इम्प्लीमेंटिंग एक्ट्स के लागू होने की तारीख़ से अधिकतम 36 महीनों के भीतर, और केवल यूज़र के स्वैच्छिक अनुरोध पर, यूरोपियन डिजिटल आइडेंटिटी वॉलेट भी स्वीकार करेंगी"। टेक्स्ट परिवहन, ऊर्जा, बैंकिंग, वित्तीय सेवाएँ, सामाजिक सुरक्षा, स्वास्थ्य, पीने का पानी, डाक सेवाएँ, डिजिटल इंफ़्रास्ट्रक्चर, शिक्षा और दूरसंचार के नाम लेता है, और माइक्रो तथा छोटे उद्यमों को बाहर रखता है।
  • बहुत बड़े ऑनलाइन प्लेटफ़ॉर्म। अनुच्छेद 5f(3) इन्हें यूज़र ऑथेंटिकेशन के लिए वॉलेट स्वीकार करने को बाध्य करता है, फिर से सिर्फ़ यूज़र के स्वैच्छिक अनुरोध पर और ज़रूरी न्यूनतम डेटा के लिए।
  • इम्प्लीमेंटिंग एक्ट्स में बदलाव। Implementing Reg. (EU) 2024/2979 का रिसाइटल 4 कहता है कि कमीशन को ज़रूरत पड़ने पर इसकी "समीक्षा करनी चाहिए और इसे अपडेट करना चाहिए"। कोई मैपिंग फ़्रीज़ करने से पहले 2024/2977 की एट्रिब्यूट तालिकाएँ जाँच लें।

व्यावहारिक निष्कर्ष: जब आपके यूज़र्स के देश अपने वॉलेट जारी करें तब वॉलेट वाला रास्ता बनाएँ, दस्तावेज़ वाला रास्ता बनाए रखें, और पहले दिन से दोनों को एक रिकॉर्ड में मैप करें। पासपोर्ट और ID कार्ड OCR API की डॉक्स स्कैन वाले पहलू को पूरी तरह कवर करती हैं।

यह एक इंजीनियरिंग सारांश है, क़ानूनी सलाह नहीं।