التوقيع الصحيح لا يثبت ما عُرض على صاحب الموافقة

الخلاصة

• تقر المراجعة 01 من مسودة إنترنت فردية بأن العرض الحتمي يكشف التعارض بين الفعل الموقّع والصورة المعلنة، لكنه لا يثبت ما أظهرته شاشة غير موثوقة للإنسان.
• تشترط المسودة إبقاء التحقق من إيصال التفويض والتحقق من دليل العرض نتيجتين منفصلتين؛ نجاح أي منهما لا يعني أن الفعل أصبح مأذوناً.
• يقترح Daniel Kade سجل قرار للعرض يربط الأدلة بتسجيل المفتاح وصلاحية الشخص وجذور الثقة والمخاطر المتبقية وسياسة الجهة المعتمدة. هذا اقتراح تحريري لا نص معياري في المسودة.

المراجعة الجديدة تصحح ادعاءً لا خوارزمية فقط

يبدأ التغيير من السؤال: من الذي وقّع؟ كانت النسخة السابقة تصف شخصاً مسمىً ينتج توقيعاً مؤكداً من المستخدم. أما المراجعة 01 فتصف مفتاحاً مسجلاً ينتج ذلك التوقيع. هذا هو الحد الذي تستطيع التشفيرات إثباته. ربط المفتاح بشخص، والتحقق من بقائه في وظيفته، وتحديد سقف صلاحياته، كلها أمور تأتي من سجلات أخرى.

ويكشف الفرق الرسمي بين 00 و01 عن تراجع مقصود عن وعد أوسع. لم يعد النص يقول إن المدقق يستطيع إثبات ما عُرض على الإنسان. بل يستطيع إعادة اشتقاق العرض المعلن من بيانات الفعل الموقعة ومقارنة البايتات. يمكن لعميل مخترق أن يرسل العرض الصحيح إلى المدقق، بينما يعرض على المستخدم صورة أخرى عبر طبقة أو قناة لا يراها البروتوكول.

تسجل صفحة Datatracker التحديث في 12 سبتمبر 2026 بوصفه مسودة إنترنت فردية نشطة. لا تنتمي إلى مجموعة عمل، ولا إلى مسار IETF، ولا يوجد لها مدير منطقة مسؤول أو حالة RFC مستهدفة مسجلة. نشرها لا يثبت تبني IETF أو إجماعها أو اعتمادها معياراً.

قابلية إعادة الإنتاج دليل محدود النطاق

يعرف المقترح العارض بوصفه دالة خالصة للفعل المعياري. ينبغي للفعل نفسه أن ينتج البايتات نفسها في كل بيئة متوافقة، بصرف النظر عن الوقت أو إعدادات الجهاز أو العشوائية أو المدخلات الخارجية. يثبت الملف مجموعة الحقول وترتيبها وطريقة تحويلها، ويستند إلى RFC 8785 في تقنين JSON.

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

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

لهذا تضيف المراجعة فقرة صريحة: يقيّم الطرف المعتمد الإيصال ودليل العرض على أساس مدخلات ثقة مستقلة. لا يجوز رفع إيصال صحيح إلى حالة «عرض مقبول» لمجرد نجاح توقيعه، ولا تحويل دليل عرض صحيح إلى تفويض لمجرد نجاح الربط.

الحماية العتادية لها شروط وفشل محتمل

تشير المسودة إلى Android Protected Confirmation كمثال قد يوضع له ملف مستقل، لكنها لا تعرف ذلك الملف. تشرح وثائق ConfirmationPrompt الرسمية أن الطرف المعتمد يفحص سلسلة شهادة المفتاح والجذر المتوقع والقيمة العشوائية الحديثة ونص الطلب الدقيق الذي جرى تأكيده. كما توضح أن الميزة تحتاج إلى عتاد مخصص وقد لا تكون متاحة دائماً.

لذلك لا تكفي خانة عامة تقول «مدعوم بالعتاد». ينبغي تسجيل الجذر المقبول، وما أثبتته شهادة المفتاح، وحداثة القيمة العشوائية، والنص المرتبط، والحقول الجوهرية التي لم تظهر، والمسار البديل عند تعذر الحماية. الرجوع الصامت إلى نافذة عادية يغير درجة الدليل ويجب ألا يرث القرار السابق.

والأمر نفسه ينطبق على التطبيق المرجعي الذي تذكره المسودة. يمكن لمتجهات اختبار سلبية أن تبين أن شفرة بعينها ترفض اختلافاً أو مدخلاً مضللاً، لكنها لا تثبت مراجعة مستقلة أو انتشاراً أو سلامة الجهاز أو صلاحية الإنسان. ولا تطلب المراجعة 01 إجراءً من IANA؛ فتسجيل المعرفات مؤجل.

القرار المحلي يحتاج إلى هوية وسجل

يقترح Daniel Kade سجل قرار للعرض تحتفظ به المؤسسة التي تتحمل نتيجة التنفيذ. يضم السجل خلاصة الفعل وملف الإيصال ونتيجة التحقق؛ وملف العارض ونسخته ولغته وحقوله الجوهرية وخلاصة عرضه؛ ونتيجة إفادة الشاشة؛ وهوية العميل وسلسلة الإثبات وجذر الثقة وفئة مسار العرض؛ ودليل ربط المفتاح بالشخص؛ ودوره وحدود صلاحياته ومدتها؛ وتصنيف الخطر المتبقي؛ وسياسة التفويض المنفصلة وقرارها وسببها؛ والمراجع والتوقيت والانتهاء ومسار الرفض أو الطوارئ ومحفزات إعادة النظر.

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

يتفق ذلك مع Minimum Initial Specification لـ Heng Lu: تثبيت واجهة مشتركة صغيرة من دون مصادرة القرارات المقبلة. ويدعو The Policy Mirror إلى حفظ ما قالته كل جهة ضمن نطاقه الحقيقي. أما Why BTW Media Exists فيحفظ حد الخبر: التصحيح الجوهري في مسودة فردية واقعة؛ التبني والانتشار والإثبات الأمني ليست وقائع مثبتة بعد.

المصادر

1. سجل Datatracker
2. تاريخ المسودة
3. واجهة بيانات Datatracker
4. المراجعة 01
5. المراجعة 00
6. الفرق الرسمي
7. مسودة Authorization Receipts
8. المراجعة 13 من Authorization Receipts
9. RFC 8785
10. Android ConfirmationPrompt
11. Android Protected Confirmation
12. إثبات مفتاح Android
13. The Policy Mirror
14. Minimum Initial Specification
15. Why BTW Media Exists