ما الذي يجب أن يظهر في صفحة التحقق من رمز QR للتقرير؟

إجابة مختصرة: ما مهمة صفحة التحقق؟

يجب أن تعرض الصفحة هوية التقرير، والمراجعة الحالية، وحالة النشر، ونتيجة التوقيع والسلامة، ووقت التحقق؛ ولا يجب أن تعرض للعموم بيانات شخصية غير لازمة أو المحتوى الكامل للتقرير.

رمز QR مجرد ناقل يقود إلى العنوان الصحيح. أما ما يبني الثقة فهو مطابقة الصفحة المفتوحة لسجل التقرير القانوني مطابقةً حيّة، وعدم اعتبار النتيجة الغامضة نتيجةً صحيحة، وشرح ما يتم التحقق منه للمستخدم بوضوح.

ما المعلومات الواجب توفرها في صفحة التحقق؟

إجابة مختصرة: يجب أن يرى المستخدم النتيجة أولًا، ثم أي تقرير وأي إصدار أُنتجت هذه النتيجة بشأنهما. يجب أن تشرح التفاصيل التقنية النتيجة لا أن تحجب رسالتها الرئيسية.

تشير إرشادات BTK بشأن التوقيع الإلكتروني إلى أن التوقيع الإلكتروني الآمن يتيح تحديد هوية الموقِّع ومعرفة ما إذا أُجرِي تعديل لاحق على البيانات الموقَّعة. لذلك فإن «وُجد السجل» و«تم التحقق من التوقيع وسلامة المحتوى» ليسا الحالة نفسها.

كيف ينبغي التمييز بين صحيح وغير صحيح وتعذّر التحقق؟

يجب الفصل بين الحالات الثلاث بخطوط قاطعة. فخطأ الخدمة أو نقص الدليل ليس تحققًا ناجحًا.

• صحيح: وُجد إصدار التقرير المطلوب، وحالة النشر مناسبة، واكتملت فحوصات التوقيع والسلامة بنجاح وفق السياسة المحددة.
• غير صحيح: تغيّر المحتوى، أو فشل التوقيع من الناحية التشفيرية، أو أن السجل في حالة إلغاء/عدم صلاحية معلنة صراحةً.
• تعذّر التحقق: تعذّر الحصول على حالة الشهادة، أو لم تستجب خدمة التحقق، أو كان الدليل ناقصًا، أو تعذّر إصدار قرار بشأن سلامة السجل.

ينص المعيار ETSI TS 119 102-2 على أثر منظّم في تقرير التحقق يتضمن، إلى جانب النتيجة، بيانات المُتحقِّق وكائنات التحقق المستخدمة. أما المقابل التقني في تطبيق VizyonTech فهو عرض نتيجة مبسطة للمستخدم النهائي مع الاحتفاظ، في سجل التدقيق، بمراجع المُتحقِّق والسياسة/الإصدار والأدلة التقنية المرتبطة بالنتيجة.

يجب ألا تعرض شاشة الخطأ غير المتوقع أثر المكدس، أو معرف قاعدة البيانات، أو مسار الشهادة، أو اسم الخدمة الداخلية. ووفق نهج OWASP القائم على الرفض افتراضيًا، ينبغي أن تبقى النتيجة «تعذّر التحقق» عند خطأ النظام، وأن يُقدَّم للمستخدم مرجع دعم آمن.

إلى أي مدى ينبغي عرض تفاصيل نتيجة التوقيع الإلكتروني؟

إجابة مختصرة: يجب عرض ملخص مبسط وقابل للتحقق من الفحوصات التقنية المنفذة، لا شارة تُقرِّر الحكم القانوني.

وجود التوقيع وحده لا يعني أن التقرير حديث أو مرخَّص تشغيليًا. يجب أن تميز الشاشة على الأقل بين نتيجة سلامة التوقيع، ووقت التوقيع، ووقت فحص الشهادة، ونتيجة الطابع الزمني إن وُجدت. وإذا عُرضت هوية الموقِّع، فيجب الاقتصار على الحقول اللازمة لغرض التحقق فقط.

يتناول البند 32 من لائحة eIDAS، في صورة شروط منفصلة، صفة الشهادة وصلاحيتها وقت التوقيع، وبيانات التحقق من التوقيع، وبيانات الموقِّع، وإمكانية اكتشاف المشكلات المتعلقة بالأمان. أما في الممارسة التركية فيجب تقييم التشريعات النافذة وسياسة الجهة أيضًا؛ ولا ينبغي أن تُنتج الصفحة، استنادًا إلى الفحص التقني وحده، ادعاءً باليقين القانوني خارج نطاقها.

لتصميم مسار التقرير قبل التوقيع دليل سير عمل التوقيع الإلكتروني في تقارير الفحص يمكنكم الاطلاع. فصفحة QR هي واجهة التحقق المتحكم بها التي تفتح تلك السلسلة للمستخدم الخارجي.

ما المعلومات التي يجب ألا تكون متاحة للعموم؟

إجابة مختصرة: لا تعرض في الصفحة العامة التفاصيل الشخصية والتجارية والتقنية غير اللازمة للتحقق؛ وانقل التقرير المفصل إلى وصول مخوَّل.

تتطلب المبادئ الأساسية لقانون KVKK معالجة البيانات الشخصية بشكل مرتبط بالغرض ومحدود ومتناسب. ويجب افتراض إمكانية مشاركة رابط QR من قبل أطراف ثالثة؛ وأن يُصمَّم العرض العام وفق هذه المخاطرة.

• لا تعرض بيانات شخصية مباشرة مثل رقم الهوية الوطنية والعنوان والهاتف والبريد الإلكتروني.
• لا تنشر صورة التوقيع اليدوي، والتفاصيل غير الضرورية للشهادة، والرقم التسلسلي الكامل.
• لا تفتح افتراضيًا البيانات السرية لمنشأة العميل، وملاحق القياس، وملف PDF الكامل للتقرير.
• إن لم يكن اسم الموقِّع ضروريًا فاستخدم الدور أو اسمًا مقنَّعًا؛ ووثِّق الضرورة بغرض معالجة البيانات.
• احمِ تنزيل الملف المفصل بالتحقق من الهوية والصلاحية وسجل المعاملات.

كيف ينبغي عرض معلومات المراجعة والإلغاء؟

بدلًا من إخفاء التقرير القديم بصمت، صرّح عن حالته بوضوح وقدّم رابطًا آمنًا إلى الإصدار الحالي. بهذه الطريقة يمكن التحقق بأثر رجعي من ملفات PDF القديمة الموزَّعة.

يجب التمييز بين حالات «الإصدار الحالي» و«صدرت مراجعة جديدة بدلًا منه» و«أُلغي» و«بانتظار النشر». وإذا كان سبب الإلغاء يتضمن معلومات حساسة فيُعرض التصنيف العام فقط، وتُترك التفاصيل للمستخدم المخوَّل. ويجب ألا تستبدل المراجعة الجديدة عنوان URL للسجل القديم أو تاريخه، بل تُحفَظ العلاقة بين السجلين في أثر التدقيق.

كيف ينبغي أن تكون تجربة التحقق عبر الهاتف وإمكانية الوصول؟

يجب أن تكون النتيجة مفهومة على شاشة واحدة، بسرعة، ودون الاعتماد على اللون وحده. وبما أن رمز QR يُفتح غالبًا من الهاتف، ينبغي أن يعرض العرض الأول هوية التقرير والنتيجة معًا.

• قدّم الحالة بالنص والأيقونة وتباين لوني كافٍ.
• أبلغ التقنيات المساعدة بتغييرات الحالة عبر منطقة حيّة مناسبة أو دور حالة مناسب.
• اجعل أهداف اللمس سهلة الاختيار؛ ولا تُرغِم المستخدم على تمرير الجدول أفقيًا.
• أظهِر بوضوح أن الرابط على نطاق VizyonTech الحقيقي وعبر HTTPS.
• إذا تعذّر قراءة رمز QR فوفّر استعلامًا بديلًا برقم التقرير ورمز التحقق الآمن.

يتطلب معيار WCAG 2.2 وجود بدائل نصية، ومحتوى مفهوم، وقابلية تحديد رسائل الحالة برمجيًا. لذلك لا يكفي اللون الأخضر/الأحمر أو علامة الصح/الخطأ وحدها.

كيف ينبغي تجربة تدفق التحقق لدى VizyonTech؟

حل Vizyon Periyodik عند التقييم، جرّب بأمثلة واقعية لكن مجرّدة من البيانات الشخصية السيناريوهات التالية على الأقل: تقرير حالي وصحيح، ومراجعة قديمة، وسجل ملغى، وملف معدَّل، وانتهاء مهلة خدمة التحقق، ومحاولة وصول غير مخوَّل إلى التقرير الكامل.

معيار النجاح ليس مجرد فتح رمز QR. هل يفهم المستخدم أي تقرير يتحقق منه؟ هل يبقى النظام مغلقًا عند الحالة الغامضة؟ هل تسرّبت بيانات غير لازمة؟ هل تُقرأ النتيجة على شاشة الهاتف؟ وهل يستطيع فريق الدعم تتبع الحادث بالرمز المرجعي الآمن؟ يجب أن ينتج التطبيق التجريبي أدلة على هذه الأسئلة.