الخلاصة

  • تقترح النسخة ‎-02 من مسودة فردية أن يرفض المتحقّق الرمز كله إن عجز عن تقييم أي عنصر من authorization_details، بدلاً من إسقاط العنصر المجهول والإعلان أن التقييم اكتمل بنجاح.
  • ينبغي للمتصل أن يفهم أن إعادة إرسال الرمز المقدّم نفسه لن تغيّر النتيجة، من دون أن يحصل على اسم عنصر التفويض أو المسار أو المنحة التي فشلت. تبقى التفاصيل الدقيقة في سجل تدقيق يحكمه مشغّل جهة التحقق.

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

هذه هي المسألة التي أبرزتها نسخة 29 سبتمبر 2026 من Verifier-Side Evaluation Semantics for Delegated Authority Chains لوِس جاكسون. يصنّفها سجل IETF Datatracker مشروع إنترنت فردياً في حالة I-D Exists، بلا مسار معايير محدد. ليست نصاً اعتمدته مجموعة WIMSE ولا وثيقة RFC ولا دليلاً على نشر منتج. ألفاظ الإلزام الواردة فيها تعبّر عن اقتراح صاحبها، ولا يجوز عرضها على أنها قاعدة أقرتها IETF بالفعل.

تكشف المقارنة مع النسخة ‎-01 عن تغيير ذي معنى. كان عنوان القاعدة الأولى «معالجة كل عنصر أو Reject»، وأصبح في النسخة الجديدة «معالجة كل عنصر أو Refuse». تفصل المسودة الآن بين رفض المتحقّق قبول رمز أو سجل، وبين رفض صاحب الموافقة النهائي لتنفيذ استدعاء كان معلّقاً. الأول قرار بشأن إمكانية تقييم دليل السلطة، والثاني حكم بشري بشأن فعل معيّن. جمعهما تحت كلمة واحدة يطمس مَن يملك القرار وما الذي انتهى بالفعل.

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

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

لا تكفي الإشارة إلى رموز أخطاء OAuth من دون تمييز موضع استخدامها. ينص RFC 9396 على invalid_authorization_details عند خادم التخويل لمعلومات تخويل مجهولة أو غير سليمة، ويسجل الرمز لطرفَي التخويل وإصدار الرمز. أما RFC 6750 فيعرّف invalid_token عند خادم الموارد الذي يستقبل رمز حامل، ويجيز للعميل أن يطلب رمز وصول جديداً ثم يعيد الطلب. تذكر مسودة جاكسون السياقين، لكنها لا تسجل رمزاً جديداً ولا تحدد صيغة رد عامة. لذلك لا يصح تحويل «لا تكرر هذا الرمز» إلى «لا تحاول بأي رمز آخر».

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

المصادر