الخلاصة

  • طُرحت في 28 سبتمبر 2026 النسخة الأولى من Internet-Draft فردية تقترح client_instance_id يعيّنه مُصدِر الإثبات، ويمكن إبقاؤه عند التحقق من تبديل مفتاح المثيل نفسه. لا يمثل النص RFC أو تبنّياً من فريق عمل أو دليلاً على التنفيذ.
  • لا تعيد المسودة ربط رمز تحديث سابق بالمفتاح الجديد. وفق القاعدة الافتراضية في المسودة الأساسية، يفشل طلب التحديث بالمفتاح البديل ولو طابقت هوية المثيل، ما لم يغيّر ملف تعريف منفصل منطبق قاعدة الربط صراحة.
  • على خادم التفويض أن يقارن إثباتاً حديثاً بهوية المثيل الأصلية المسجلة للمنحة، وأن يتحقق بصورة مستقلة من شرط ربط الرمز بالمفتاح وإثبات حيازته.

نجاح التحقق الأول لا يفتح الباب الثاني

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

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

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

ما الذي يجعل المثيل «نفسه»؟

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

المعرف، افتراضياً، خاص بجهة استقبال واحدة تسمّيها المسودة Receiver. ليس رقماً عالمياً ثابتاً يسمح بتتبع التطبيق في كل خدمة. اختيار النطاق وفصل المفاتيح مسؤولية في التصميم والتنفيذ؛ لا تستطيع جهة استقبال أن تستنتج وحدها من إثباتها أن الفواصل احترمت في الجهات الأخرى. وتؤكد المسودة أن هوية المثيل لا تمنح صلاحية بذاتها، ولا تحدد sub، ولا تمد سلسلة act، ولا تغني عن إثبات حيازة المفتاح. إظهار client_instance اختيارياً في الرمز أو الاستعلام عن حالته يضيف سياقاً عن التثبيت، لا تفويضاً جديداً.

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

يعرض سجل Datatracker النص بوصفه أول إصدار فردي وحالته I-D Exists. وعبارة Standards Track فيه تصف المسار المنشود لا معياراً أُقر. لا تقدم المصادر المعتمدة هنا دليلاً مستقلاً على تشغيل فعلي أو اختبارات توافق أو حادث أمني. ما سبق قراءة للضوابط المقترحة، لا وصف لاعتماد واقع.

المصادر