التطبيق ثابت، وباب الوكيل يتبدّل من ملف صغير

Summary

• تضع المسودة مسارات الوكلاء وخوادم التفويض وواجهات الاستدعاء في /.well-known/agent-capabilities على أصل الخدمة.
• العملية غير المدرجة في أي مسار معلن مغلقة؛ لا يجوز لخادم الموارد تنفيذها حتى لو ظهرت في حالة تفويض أُقرت سابقاً.

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

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

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

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