الخلاصة

  • يتيح draft-ietf-oauth-status-list-21 للـ Referenced Token أن يشير بواسطة URI وفهرس إلى خانة في قائمة مضغوطة. ويمكن لـ Status List Token المحمي أن يحمل حالات VALID وINVALID وSUSPENDED أو قيماً خاصة بالتطبيق لعدد كبير من الرموز. النسخة 21 Internet-Draft أقرّها IESG وهي في طابور RFC Editor، لكنها لم تصبح RFC بعد.
  • تصف الخانة افتراضياً الحالة التي أكدها Status Issuer عند إصدار القائمة. تضبط iat وexp وttl الإصدار والصلاحية والتخزين المؤقت؛ ولا تسجل تلقائياً لحظة الانتقال الأصلية أو صاحب السلطة أو السبب أو أول إتاحة لدى Provider أو قرار relying party.
  • يقترح Daniel Kade إيصال قرار مصغراً خارج البروتوكول: بصمتا الرمز والقائمة، URI والفهرس، تحقق جهة الإصدار، أربع ساعات منفصلة، المعنى المفكوك، سياسة الحداثة المحلية، الإجراء والتصحيح اللاحق. هذا توجيه تحريري لا مطلب من IETF، ولا مبرر لبناء سجل مراقبة دائم لعروض الهوية.

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

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

وثيقة مقرة في مسار التحرير وليست RFC بعد

تعرّف صفحة Datatracker النسخة 21 المؤرخة في 21 يونيو 2026 بأنها Internet-Draft على Standards Track لدى OAuth Working Group. ويسجل التاريخ موافقة IESG على النسخة 20 في 4 يونيو، ثم نقل الوثيقة إلى طابور RFC Editor، ونشر النسخة 21 في 21 يونيو، ووصول حالة RFC Production Center إلى Awaiting First editor في 13 أغسطس. إنه تقدم رسمي مهم، لكنه ليس رقماً نهائياً لـ RFC.

تنتهي صلاحية نص النسخة 21 في 23 ديسمبر 2026، ويحدد الفرق الرسمي بين 20 و21 حدود النص المدروس. لا يثبت موقع الوثيقة في الطابور انتشار التنفيذ أو امتثاله. ويتولى OAuth Working Group النص المعياري، لا الخدمات الافتراضية في أمثلة هذا المقال.

يشمل النطاق رموزاً محمية عبر JOSE أو COSE، مثل JWT وSD-JWT وCWT واستخدامات ISO mdoc. يوفر RFC 7515 أساس JWS و RFC 7519 أساس JWT، بينما يعرّف RFC 8392 CWT و RFC 9052 بنى COSE. قائمة الحالة ليست نسخة أخرى من وثيقة الهوية؛ إنها بيان محمي منفصل عن حالة يمكن أن تتغير بعد إصدار الوثيقة.

الإحداثي يدل على الخانة ولا يدل على سببها

عند استخدام آلية القائمة، يحمل Referenced Token كائن status_list وفيه uri وidx. يحدد الأول مكان Status List Token، ويحدد الثاني موضعاً صحيحاً غير سالب للقراءة. هذه الإحداثيات تكفي للوصول، لكنها لا تتضمن قراراً إدارياً أو سبباً أو توقيع الشخص الذي أمر بالتغيير.

يختار Status Issuer بتاً واحداً أو بتين أو أربعة أو ثمانية لكل رمز. يخصص فهارس مستقلة، ويرتب القيم داخل البايت من البت الأقل أهمية إلى الأعلى، ثم يضغط المصفوفة بخوارزمية DEFLATE ضمن صيغة ZLIB. يعرّف RFC 1951 DEFLATE ويعرّف RFC 1950 الغلاف. توضع النتيجة داخل JWT أو CWT وتحميها توقيعة أو MAC.

يفصل النموذج بين Issuer وStatus Issuer وStatus Provider. يصدر الأول Referenced Token، ويتلقى الثاني معلومات الحالة ويصنع البيان المحمي، ويقدمه الثالث. قد تؤدي مؤسسة واحدة الوظائف الثلاث، وقد تستضيف القائمة جهة خارجية أو CDN من دون أن تكتسب حق تغيير البايتات الموقعة.

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

يضع السجل الأولي دلالات محددة: 0x00 لـVALID، و0x01 لـINVALID، و0x02 لـSUSPENDED، مع نطاقات مخصصة للتطبيق والتسجيل المستقبلي. وإذا استعملت الخانة أكثر من بت فإن المجموعة كلها تمثل قيمة واحدة. ليست سلسلة مصغرة من الأحداث.

ولا تلغي VALID قواعد Referenced Token. يجب أولاً فحص صيغته وتوقيعه وclaims المطلوبة وانتهاء صلاحيته. يبقى الرمز المنتهي منتهياً حتى لو قالت القائمة إنه VALID. وبعد تفسير الحالة يطبق relying party القيود المحلية. لذلك يختلف نجاح تحقق الرمز عن نجاح تحقق القائمة، وعن الحالة المقروءة، وعن قرار السماح النهائي.

أربع ساعات لا ساعة واحدة

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

الساعة الثانية هي إصدار القائمة. iat إلزامية وتذكر متى صدر Status List Token. أما exp الموصى بها فتحدد متى يعتبر Status Issuer الكائن منتهياً. تحد هاتان القيمتان الفترة التي يمكن فيها الاعتماد على البيان، لكن iat ليست تلقائياً لحظة إلغاء كل خانة.

الساعة الثالثة للتوزيع والاسترجاع. قد تسافر القائمة عبر Provider مستقل أو CDN. يرى relying party نسخة في وقت الاسترجاع، وربما بعد إصدارها. وقت المشاهدة مهم، لكنه لا يساوي وقت الإنشاء أو وقت حدث المصدر.

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

تنظم ttl التخزين المؤقت من دون أن تدمج الساعات. تصف النسخة 21 خيار إعادة الفحص بعد «وقت الاسترجاع + ttl» لتوزيع الحمل، وخيار iat + ttl لحالات تحتاج إلى أحدث معلومة مع هامش صغير للإصدار والتوزيع. وإذا تعارضت ترويسات HTTP مع claims المحمية، تُقدَّم exp وttl داخل Status List Token. يقدم RFC 9110 دلالات HTTP، لكن النظام البيئي وrelying party يختاران الحد المقبول.

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

طلب لقطة قديمة لا ينتج محضر انتقال

يعيد المسار الافتراضي أحدث معلومة. وتوجد وظيفة اختيارية ترسل time=<timestamp>. يمكن للخادم الداعم أن يعيد قائمة صالحة لذلك الوقت أو خطأ. وإذا تجاهلت استضافة ثابتة معامل الاستعلام وأعادت القائمة الحالية، فعلى العميل رفضها ما لم يقع الوقت المطلوب داخل نافذة iat وexp المحمية.

تفيد اللقطات في تضييق النطاق. إذا كانت الخانة VALID في العاشرة وINVALID في العاشرة والربع، نعرف أن البيان تبدل بين القائمتين. لا نعرف من ذلك وحده هل صدر الأمر في 10:02، أو عُدّل نظام المصدر في 10:07، أو أصبحت النسخة متاحة في 10:14. الزمن الدقيق والسلطة والسبب تحتاج إلى سجل آخر.

وللبحث التاريخي ثمن خصوصية. توصي الوثيقة بعدم دعمه من دون سبب قوي وفهم للعواقب. يمكن لمتحقق يحتفظ بـURI والفهرس ويكرر الاستعلام أن يبني ملفاً عن حياة الوثيقة. ويمكن لمراقب خارجي أن يؤرشف القوائم ويستنتج أحجام الإصدار أو نسب الإلغاء. إثبات قرار واحد لا يبرر مراقبة الجميع.

خصوصية القطيع لها حدود

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

لكن البيانات الوصفية قد تضيق القطيع. URI فريد لكل رمز، أو قائمة صغيرة جداً، أو حجم مميز، يكشف أكثر. وقد يظهر عنوان relying party في طلب HTTP. كما أن زوج URI والفهرس قابل للربط، ويمكن لجهات تحقق متعاونة مقارنة العروض. يوفر RFC 9901 سياق الإفصاح الانتقائي في SD-JWT، ويعرّف RFC 9458 Oblivious HTTP، وهو مثال على relay يقلل معرفة جهة الاستضافة بالمرسل.

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

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

فك الترميز خطوة قرار

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

يجب أن يبقى التسلسل ظاهراً: تحقق أولاً من Referenced Token؛ حل URI؛ تحقق من نوع Status List Token وتوقيعه أو MAC وclaims؛ اربط subject بالـURI؛ طبق iat وexp وttl وسياسة الحداثة؛ فك الضغط؛ اقرأ الفهرس؛ فسر القيمة المسجلة؛ ثم طبق قاعدة التطبيق.

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

إيصال ببصمتين وأربع ساعات

يبدأ اقتراح Daniel Kade ببصمة مصغرة لـReferenced Token وبصمة دقيقة لـStatus List Token المستعمل. يسجل URI والفهرس وStatus Issuer وProvider المرصود وحل المفتاح ونتيجة التوقيع أو MAC ونسخة أداة فك الترميز أو دليل اختبارها.

ثم يفصل وقت التغيير في المصدر إن كان معلوماً، ويكتبه «غير معلوم» إن لم يكن؛ ويحفظ iat وexp وttl ووقت الاسترجاع وعمر النسخة وقت الاستخدام ووقت القرار. ويذكر هل كان الطلب حالياً أو تاريخياً، والتوقيت المطلوب، والقيمة الرقمية ومعناها المسجل، والحد المحلي، والقاعدة، والإجراء، وأي تصحيح أو إغلاق لاحق.

هذا ليس تعديلاً مقترحاً على Token Status List، بل رقابة محلية متناسبة مع النتائج الدائمة. يفضل hashes والمراجع والاحتفاظ المحدود. يلهم The Policy Mirror مقارنة القاعدة بالقرار المرصود، ويعيد Running-Code Primacy الانتباه إلى المسار المنفذ، ويحفظ Reality, Not Advocacy المجهول من أن يتحول إلى ادعاء. ليست هذه المقالات دليلاً على حادث OAuth حقيقي.

المصادر