الخلاصة

  • تخبر TRL في RFC 9770 الأجهزة المسجلة بهاشات tokens الملغاة غير المنتهية، لكنها تقر بوجود فترة يمكن أن ينجح فيها الوصول قبل أن يعلم RS بالإلغاء.
  • قرار الإلغاء، تحديث AS، الإشعار أو الاستعلام، الاستلام، حذف الـtoken محلياً، ونتيجة الطلب اللاحق طبقات أدلة مختلفة.

تبدو كلمة «ملغى» كأنها أمر واحد نفذ في كل مكان. في بيئة ACE هي سلسلة موزعة. صدرت RFC 9770 في 2025 كعمل مشترك لـMarco Tiloca وFrancesca Palombini وSamuel Echeverria وGrace Lewis. يستطيع العميل أو Resource Server المسجل أن يطلب قائمة Token Revocation List الكاملة أو فروقها عبر CoAP، أو أن يراقبها باستخدام Observe. تحتوي القائمة على hash يعرّف token في هذه الآلية؛ ولا تثبت هوية مستخدم أو سبب قرار أو نتيجة طلب محمي.

تحفظ المواصفة هذا الحد بوضوح. كيفية إعلان token ملغى، وكيف يعلم Authorization Server بذلك، خارج نطاقها. لذلك لا يثبت إدخال في TRL وحده أن سياسة ما كانت سليمة أو أن اختراقاً وقع أو أن مسؤولاً اتخذ قراراً صحيحاً. إنه يثبت تغير تمثيل الخادم.

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

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

تسمي RFC النافذة الخطرة مباشرة: يمكن للعميل أن يصل إلى مورد بعد الإلغاء وقبل علم RS؛ وإن كان RS لا يزال يخزن الـtoken فقد ينجح الوصول، وهو خرق أمني. لذلك لا تكفي شاشة مركزية تقول «revoked». الدليل الحاسم هو ما وصل إلى جهة التطبيق وما فعلته فعلاً.

عدسة Heng Lu تضع TRL في موضعها: سطح مشترك محدود للتنسيق، لا سيادة على الاتصال أو الاستعلام أو التخزين أو القرار الجاري في كل جهاز.

المصادر