إذا كان تطبيقك يطلب اليوم من المستخدمين صورة جواز السفر أو بطاقة الهوية، فالأرجح أنك سمعت أن محافظ الهوية الرقمية الأوروبية (EUDI Wallet) ستصل «في نهاية 2026». التاريخ حقيقي ودقيق: 24 ديسمبر 2026. لكنه موعد نهائي للدول الأعضاء لا لك، ولا يوقف مسح الوثائق.

يقوم هذا المقال بثلاثة أمور. يبيّن من أين يأتي التاريخ، مع الحساب. ويسرد ما تسلّمه المحفظة فعلًا، انطلاقًا من جداول السمات في النصوص القانونية. ويرسم تصميمًا يقبل المحفظة حين يملكها المستخدم ويعود إلى مسح الوثيقة حين لا يملكها. كاتب المقال هو doc.cheap، وهي واجهة API للتعرّف على جوازات السفر وبطاقات الهوية، فاقرأ الأجزاء المتعلقة بالمنتج مع أخذ ذلك في الحسبان. تقرأ doc.cheap صور الوثائق؛ ولا تقرأ المحافظ.

من أين يأتي 24 ديسمبر 2026

الالتزام هو المادة 5a(1) من اللائحة (EU) رقم 910/2014، التي أُدرجت بموجب اللائحة (EU) 2024/1183، وهي تعديل eIDAS. تنص على أن كل دولة عضو «تُتيح محفظة هوية رقمية أوروبية واحدة على الأقل في غضون 24 شهرًا من تاريخ دخول الأفعال التنفيذية المشار إليها في الفقرة 23 من هذه المادة وفي المادة 5c(6) حيّز النفاذ».

إذن لا تبدأ الساعة بتعديل eIDAS نفسه. بل تبدأ بالأفعال التنفيذية للمفوضية. أفعال المادة 5a(23) هي أربعة أفعال تنفيذية للمفوضية مؤرخة في 28 نوفمبر 2024، من بينها اللائحة التنفيذية (EU) 2024/2979 بشأن سلامة المحافظ ووظائفها الأساسية. نُشرت في الجريدة الرسمية (OJ L, 2024/2979) في 4 ديسمبر 2024. وتنص مادتها 15 على أنها «تدخل حيّز النفاذ في اليوم العشرين التالي ليوم نشرها في الجريدة الرسمية للاتحاد الأوروبي».

الحساب:

الخطوة التاريخ
النشر في الجريدة الرسمية 4 ديسمبر 2024
اليوم 1 بعد النشر 5 ديسمبر 2024
اليوم 20 بعد النشر: دخول حيّز النفاذ 24 ديسمبر 2024
زائد 24 شهرًا (المادة 5a(1)): موعد استحقاق المحافظ 24 ديسمبر 2026
زائد 36 شهرًا (المادة 5f(2)): على بعض الأطراف المعتمِدة الخاصة قبول المحافظ 24 ديسمبر 2027

يُحسب «اليوم العشرون التالي» ابتداءً من اليوم الذي يلي النشر، لذا فإن 4 ديسمبر زائد 20 يومًا يقع على 24، لا على 23. والعدّ نفسه للفعل التنفيذي يحدد التاريخ الثاني في الجدول، وهو التاريخ الذي يهم معظم فرق المنتجات فعلًا (المزيد عنه أدناه).

ما الذي تسلّمه المحفظة

المحفظة لا ترسل صورة جواز سفر. بل تقدّم بيانات موقّعة. مجموعة البيانات الخاصة بالشخص الطبيعي محددة في ملحق اللائحة التنفيذية (EU) 2024/2977، وهي «بيانات تعريف الشخص» (PID). ويذكر الملحق أن PID تُصدر بصيغتين: ISO/IEC 18013-5:2021 و«Verifiable Credentials Data Model 1.1» من W3C.

إليك السمات، مع درجة الحضور التي يمنحها النص لكل منها (الجداول 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 إلزامية إدخال birth_place في fields[]، حين تطبعه الوثيقة
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 (بيانات وصفية) إلزامية إدخال authority في fields[]، حين يكون مطبوعًا
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 ستظل ترى:

  • مسافرين وعملاء من خارج الاتحاد الأوروبي. تربط الحيثيات المحفظة بـ«الهوية القانونية لمواطني الاتحاد أو المقيمين في الاتحاد أو الأشخاص الاعتباريين». والزائر الذي يحمل جواز سفر من بلد آخر لا يملك محفظة أوروبية يقدّمها.
  • أشخاصًا لم يثبّتوا محفظة، أو لا يستطيعون، أو يفضّلون ألا يفعلوا. والنص يحمي هذا الخيار.
  • مسارات تحتاج إلى الوثيقة نفسها. بعض العمليات تريد صورة الوثيقة أو رقمها أو المنطقة المقروءة آليًا في الوثيقة المادية، لا إفادة عن الشخص. تحمل 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 يكون كل مفتاح حاضرًا دائمًا، والقيمة غير المعروفة هي null. وقد ترسل المحفظة قيمة بديلة مؤقتة بدلًا من ذلك. وحّد الاثنين على اصطلاح واحد.
  4. خزّن أقل ما يحتاجه المسار. يمكن تشغيل المسح بحيث لا يُكتب شيء على جانب API (أدناه).

إليك الاستدعاء البديل باستخدام fetch فقط. مفتاح sandbox العام 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. الأولى وحدها ينبغي أن تملأ سجلًا؛ والبقية ينبغي أن تعيد المستخدم لالتقاط الصورة من جديد. ومع مفتاح مدفوع، لا يُخصم من الرصيد إلا حين يكون المسح قابلًا للفوترة.

أجرينا استدعاءً واحدًا من هذا النوع على sk_sandbox_public في 24 سبتمبر 2026 عند الساعة 21:17 UTC، باستخدام وثيقة الاختبار الخاصة بالمنتج، وهي جواز سفر. عادت الاستجابة بـ 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 نفسه فلا يُخصم منه أبدًا. تضمّنت مصفوفة fields في ذلك التشغيل إدخالات birth_place وauthority وpersonal_number، وهي المكان الذي يشير إليه الجدول أعلاه لتلك السمات من PID. تحمل صفحة بيانات جواز السفر منطقة MRZ في سطرين بتخطيط TD3؛ وصفحة صيغ TD1 وTD2 وTD3 تعرض التخطيطات جنبًا إلى جنب.

لاحظ authenticity.overall: "not_checked". مسح كهذا هو تعرّف: يقرأ ما هو مطبوع ويتحقق من أرقام التحقق في MRZ. وهو ليس كشفًا للتزوير، ولا يمنح الضمان نفسه الذي يمنحه عرض محفظة موقّع. إذا احتاجت عمليتك إلى مستوى ضمان أعلى على مسار المسح، فلا بد أن يأتي من موضع آخر في مسارك. وإذا كنت تختار مزوّدًا للمسار البديل، فإن مقارنتنا بين واجهات OCR لجوازات السفر تعرض الخيارات، بما فيها خيارات تفعل أكثر من التعرّف.

ما الذي تجب متابعته بعد ذلك

  • 24 ديسمبر 2026 – موعد استحقاق المحافظ. المادة 5a(1)، اللائحة (EU) 2024/1183، محسوبًا من دخول الأفعال التنفيذية حيّز النفاذ كما هو موضح أعلاه.
  • 24 ديسمبر 2027 – الأطراف المعتمِدة الخاصة. تنص المادة 5f(2) على أن الأطراف المعتمِدة الخاصة الملزمة باستخدام مصادقة قوية للمستخدم من أجل التعريف عبر الإنترنت، بموجب القانون أو العقد، «تقبل أيضًا محافظ الهوية الرقمية الأوروبية، في موعد لا يتجاوز 36 شهرًا من تاريخ دخول الأفعال التنفيذية المشار إليها في المادة 5a(23) والمادة 5c(6) حيّز النفاذ، وبناءً على طلب طوعي من المستخدم فقط». ويسمّي النص النقل والطاقة والخدمات المصرفية والخدمات المالية والضمان الاجتماعي والصحة ومياه الشرب والخدمات البريدية والبنية التحتية الرقمية والتعليم والاتصالات، ويستثني المؤسسات الصغرى والصغيرة.
  • المنصات الإلكترونية الكبيرة جدًا. تُلزمها المادة 5f(3) بقبول المحافظ لمصادقة المستخدمين، مرة أخرى بناءً على طلب طوعي من المستخدم فقط، وللحد الأدنى من البيانات اللازمة.
  • التعديلات على الأفعال التنفيذية. تنص الحيثية 4 من اللائحة التنفيذية (EU) 2024/2979 على أن المفوضية «ينبغي أن تراجعها وتحدّثها» عند الضرورة. راجع جداول السمات في 2024/2977 قبل أن تثبّت أي ربط.

الخلاصة العملية: ابنِ مسار المحفظة حين تطلق بلدان مستخدميك محافظها، واحتفظ بمسار الوثيقة، واربط الاثنين بسجل واحد من اليوم الأول. يغطي توثيق واجهة API للتعرّف على جوازات السفر وبطاقات الهوية جانب المسح بالكامل.

هذا ملخّص هندسي، وليس استشارة قانونية.