الخلاصة

  • تفصل النسخة -07، المؤرخة في 28 سبتمبر، من مسودة إنترنت فردية بين VERIFIED للفحص الأصلي وACCEPTED لقبول الجهة المعتمدة؛ كانت النسخة -06 تجمعهما في نتيجة واحدة.
  • إذا تعذر حل مرجع المفتاح فالتحقق NOT_EVALUATED، وليس دليلاً على فشل التوقيع. وحل المرجع لا يمنح المفتاح ثقة تلقائية للدور المطلوب.
  • لا يصبح الدليل صالحاً لمطابقة الفعل إلا بعد النتيجتين. وحتى اكتمال متطلب الأدلة SATISFIED لا يعني أن المنفذ أصدر AUTHORIZED أو أن الأثر وقع.

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

هذه هي نقطة الخبر في تنقيح Ian Schrock لمقترح Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence. تحمل النسخة الرسمية draft-schrock-ep-authorization-evidence-chain-07 تاريخ 28 سبتمبر 2026. هي Internet-Draft قدمه فرد، مع حالة Informational مقصودة بحسب غلافه؛ وليست معياراً اعتمده IETF، أو وثيقة تبناها فريق عمل، أو دليلاً على نشر نظام فعلي. كانت فكرة تركيب أدلة الهوية والتفويض والسياسة والموافقة موجودة في -06. ويحدد سجل التغييرات في -07 ما تبدل بالضبط: كانت VERIFIED القديمة تشمل الفحص الأصلي وحكم الجهة المعتمدة على مدخلات الثقة؛ أصبحت VERIFIED وACCEPTED نتيجتين منفصلتين.

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

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

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

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

تضع -07 في سجل إعادة التقييم مراجعة الخوارزمية، وبصمات الحزمة والفعل والمتطلب، والزمن، وبصمة لقطة الثقة، وحقلين مستقلين لكل مكون هما native_verification وacceptance. وينبغي أن تميز أسباب الرفض بين إخفاق الفحص، واستحالته، ورفض الثقة، وعدم تطابق الفعل. بهذه الصورة يمكن تفسير اختلاف قرارين دون الادعاء أن أحدهما اكتشف تلاعباً لم يكتشفه الآخر. السجل مخرج لتقييم مقترح، لا إذن عالمي يقدمه الوكيل. ولا تطلب المسودة أي إجراء تسجيل من IANA.

المصادر