الخلاصة

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

من يملك حق اختيار جهة الإقرار ليس بالضرورة من يملك قرار قبولها. هذا الفصل هو بداية قراءة مسودة OAuth 2.0 Client Attester Endorsement التي نشرها K. McGuinness في 28 سبتمبر 2026. يقترح النص أن يستطيع ناشر بيانات عميل OAuth أن يعلن أي الجهات يُسمح لها بالإقرار بنسخ ذلك العميل. لكن القرار النهائي لقبول إقرار بعينه يمر أيضاً عبر سياسة خادم التفويض ومصدر المفاتيح الذي يثق به. وحين يسحب الناشر تأييده، لا يملك بمجرد تحرير القائمة أن يسحب رموزاً موجودة في أيدي جهات أخرى.

هذه نسخة -00 من Internet-Draft فردية، تهدف إلى مسار Standards Track. تسجل صفحتها لدى IETF وجود المسودة، لا اعتمادها من فريق OAuth ولا صدورها RFC ولا تشغيلها فعلياً. وهي مبنية على مسودة المصادقة المبنية على إقرار العميل، ولا تنشئ اعتماداً جديداً أو طريقة مصادقة مستقلة. ما تضيفه هو علاقة قابلة للنشر بين عميل محدد وجهة إقرار: من خوّله الناشر أن يتحدث باسم نسخ هذا العميل؟

يمكن تسجيل client_attesters في بيانات عميل مسجل أو في Client ID Metadata Document. يذكر الناشر جهات الإقرار ومواقع مفاتيح التحقق منها. ووفق القسم 2.1، لا يجوز لخادم التفويض، عند معالجة طلب يخضع لهذا الملف، قبول الإقرار إلا إذا كانت بيانات العميل المعتمدة تؤيد مُصدِره حالياً وكانت سياسة الخادم تسمح بجهة الإقرار لهذا العميل وتحدد كيف تثق بمفاتيحها. يستطيع الخادم تضييق المجموعة التي أيدها الناشر، لكنه لا يستطيع إضافة جهة لم يؤيدها العميل بهذا المسار. ولا يفرض الناشر الثقة على الخادم بمجرد اختيار اسم أو رابط. كذلك لا يعني تأييد جهة إقرار منح تفويض مستخدم أو إذناً للوصول إلى مورد.

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

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

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

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

المصادر