PT-03 يضع ملخص الثقة داخل الطلب الموقّع: التجزئة لا تمنح الحجية

الخلاصة

• أُعلن draft-sato-soos-pt-03 في 5 سبتمبر 2026، وهو مسودة إنترنت فردية نشطة بلا اعتماد أو مكانة رسمية لدى IETF، ولا مسار RFC أو مدير منطقة مسؤول أو موعد اجتماع هاتفي.
• وضعت النسخة 02 ProgressiveTrustSummary في سياق HEM من دون حسم تركيب التوقيع. وتشترط النسخة 03 إدراج الملخص حقلاً داخل كل HEM Escalation Request قبل أن يوقّعه GEC.
• يمنع النص الجديد واجهة المسؤول البشري من اعتبار ملخص وصل خارج الغلاف الموقّع لطلبه ذا حجية.
• تبقى pt_summary_hash قيمة SHA-256 لـJSON المقنّن، وتفيد في مطابقة الملخص بعد استخراجه. أما أصالته وقت القرار فتأتي من kernel_signature للطلب الحاوي.
• ينبغي لإيصال موحد أن يحفظ hem_id وصورة التوقيع وهوية الموقّع والمفتاح ونتيجة التحقق ومسار الملخص وتجزئته بعد الاستخراج وتحولات الوسطاء. هذا اقتراح Daniel Kade، لا اشتراط من IETF.

قد تكون الأرقام سليمة ويكون الاقتران خاطئاً

يقدم إعلان 5 سبتمبر Progressive Trust باعتباره سجلاً سلوكياً طويل الأمد لوكلاء الذكاء الاصطناعي، يحول أحداث الجلسات إلى توصيات منظمة بشأن السلطة المقبلة. ويسجل Datatracker النسخة 03 التي كتبها Tom Sato كمسودة فردية نشطة، ويقول بوضوح إنها غير معتمدة من IETF ولا تتمتع بمكانة رسمية فيها. لم يحدد لها مسار RFC أو مدير منطقة أو موعد اجتماع. وعبارة Standards Track هي غاية المؤلف.

يقيس PT خمسة أبعاد: معايرة التقدير الذاتي، وحسن طلب التدخل البشري، والفعالية، والدقة، والتكيف بعد الرفض. ويجمع ProgressiveTrustSummary هذه القيم واتجاهاتها وعدد الجلسات والعرض المركب والتوصيات النشطة وpt_summary_hash.

يمكن أن تكون كل قيمة داخل هذا الملخص صحيحة، بينما يظهر الملخص بجوار القرار الخطأ. قد يعيد مخزن مؤقت نسخة أقدم، أو يفصل وسيط الحقول لترجمتها، أو تصل استجابة متأخرة بعد انتقال الشاشة إلى hem_id آخر. لا يحتاج المهاجم أو الخطأ إلى إفساد الرقم؛ يكفي قطع صلته بالمحفز والفعل والمتلقي.

لهذا لا تركز إضافة PT-03 على بُعد سادس للثقة، بل على وحدة التصديق: ما الكائن الكامل الذي تعهد به الموقّع؟

عبارة «داخل السياق» لم تحدد ما شمله التوقيع

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

يكشف الفارق الرسمي الإصلاح. أصبح الملخص حقلاً داخل كل HEM Escalation Request، وعلى GEC تركيبه في الطلب قبل توقيعه وفق القسم 18.8 من HEM. وتضيف النسخة قاعدة تلقي: الملخص الذي يصل خارج الغلاف الموقّع لا يجوز أن يُعامل كمرجع موثوق في واجهة المسؤول.

تنسب المسودة هذا التصحيح إلى أبرز نتيجة في WIMSE Security Review. ولم يعثر البحث العادي في المصادر العامة على نسخة مؤرشفة مستقلة من تلك المراجعة. لذلك لا تتجاوز هذه المادة نسبة القول إلى نص المسودة نفسه، ولا تخمن مضمون تقرير غير متاح. أما الفرق المنشور بين 02 و03 فيمكن التحقق منه مباشرة.

تكمن أهمية كلمة «قبل» في أنها تحول توصية عرض إلى ترتيب قابل للاختبار. قد تبدو بطاقة أضيفت بعد التوقيع جزءاً من الطلب، لكن الموقّع لم يتعهد بها. وعندما تدخل البطاقة في صورة التوقيع، يؤدي تغييرها أو نقلها إلى طلب آخر إلى فشل التحقق من الكل.

التجزئة تثبت التطابق لا التفويض

تعرّف المسودة pt_summary_hash بأنها SHA-256 لـJSON مقنّن. ويضيق النص الجديد وظيفتها عمداً: يستطيع المدقق بعد استخراج الملخص إعادة حسابها ليتأكد من أنه يفحص التمثيل نفسه. لكنها ليست مصدر الأصالة المقدم إلى الإنسان وقت التصعيد.

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

تحدد النسخة 07 من HEM الغلاف الخارجي. يوقّع GEC كامل HEM Escalation Request باستخدام Ed25519، وتغطي kernel_signature التسلسل المقنّن لكل الحقول الأخرى. كما تصف HEM-07 progressive_trust_summary بأنه حقل مطلوب في الطلب. وهكذا يختبر المتحقق ادعاءً واحداً مترابطاً: هذا الموقّع ربط هذا الملخص بهذا التصعيد.

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

يجب أن يسبق التحقق اللون الأخضر

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

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

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

الإيصال المطلوب يحفظ الوصلة نفسها

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

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

تقدم أولوية الشيفرة العاملة لدى Heng Lu منهج القراءة: نشر وثيقة ليس دليلاً على التشغيل؛ القاعدة ذات القيمة هي التي تستطيع التطبيقات المستقلة التحقق منها محلياً. وتشجع المواصفة الأولية الدنيا على طبقة مشتركة رقيقة. يكفي هنا طلب واحد وتوقيع حاوٍ ومسار تحقق محفوظ. هذه الملاحظات عدسة تحليلية وليست إثباتاً لاعتماد PT.

التصحيح منشور، أما التشغيل فلم يُثبت

لا يقدم سجلا PT وHEM على Datatracker دليلاً على تطبيق مستقل أو اختبار تشغيل بيني أو إنتاج أو هجوم أو وسيط مخترق أو حادثة أو اعتماد من IETF. تبقى الوثيقتان مسودتين فرديتين قابلتين للتغيير والانتهاء.

لذلك فالخبر الدقيق محدود وواضح: يسمي PT-03 الآن الكائن الموقّع الذي يحمل ملخص الثقة المقدم إلى الإنسان، ويعيد التجزئة إلى وظيفتها في التدقيق بعد الاستخراج. وسيأتي الدليل التالي من تطبيقين مستقلين يرفضان الاقترانات الخاطئة نفسها ويحفظان إيصالاً قابلاً لإعادة التحقق، لا من زيادة العبارات التي تتحدث عن الثقة.

المصادر

1. إعلان IETF عن draft-sato-soos-pt-03
2. Datatracker: Progressive Trust
3. أرشيف IETF: PT-03
4. أرشيف IETF: PT-02
5. المقارنة الرسمية بين PT-02 وPT-03
6. أرشيف IETF: HEM-07
7. Datatracker: Human Escalation Mechanism
8. RFC 8785: JSON Canonicalization Scheme
9. Heng Lu: Running-Code Primacy
10. Heng Lu: Minimum Initial Specification
11. Heng Lu: Reality, Not Advocacy