مسودة OCM الجديدة تجعل تفويض الخدمة غير مرئي للأطراف النظيرة

الخلاصة

• تبنت مجموعة عمل Open Cloud Mesh مسار بروتوكول التكامل، وظهرت draft-ietf-ocm-integration-protocol-00 في 11 سبتمبر 2026. وهي ما زالت Internet-Draft قابلة للتعديل، وليست RFC.
• توزع الأوضاع المجهز مسبقاً والمكتفي بذاته والقائم على الاستعلام الحالة والتوافر وزمن الإلغاء بطرق مختلفة. ويمكن كذلك إسناد إصدار الرموز إلى Token Server منفصل.
• عدم ظهور هذا التقسيم للطرف المستقبل هدف توافق في المسودة. يقترح Daniel Kade خريطة داخلية محمية للمسؤوليات والقرارات والنتائج؛ وليست هذه الخريطة مطلباً من IETF أو OCM.

التبني يحدد من يطور النص

يسجل سجل Datatracker صدور نسخة مجموعة العمل -00 في 11 سبتمبر، وأنها حلت محل سلسلة المسودة الفردية. أما رسالة إعلان النتيجة فتصف الوثيقتين المتبنتين بأنهما نقطتا بداية ستواصلان التطور. أصبحت المسودة عملاً للمجموعة، لكنها لم تصبح معياراً معتمداً ولم تثبت وجود نشر تشغيلي.

تقدم النسخة الحالية فصلاً عملياً بين الدور الاتحادي وتنفيذ بروتوكولات الوصول. يبقى OCM Server هو الخادم المرسل في نظر الاتحاد، بينما تتولى Protocol Servers خدمة WebDAV أو SSH/SFTP أو تطبيق ويب. ويمكن أن تعمل ببرمجيات وبنية تحتية مختلفتين.

وقد ينتقل إصدار الاعتماد نفسه إلى Token Server مفوض. في أحد الأشكال الخفيفة، يحتفظ OCM Server بالاكتشاف ودعوات المشاركة والإشعارات ومتابعة Shares، في حين يقع الوصول إلى المورد وإصدار الرمز في مكان آخر. تبقى الهوية الاتحادية واحدة، لكن نطاق الحوسبة الموثوقة يصبح أوسع.

أضافت أول نسخة للمجموعة نموذج تهديد إلى ما كان في النسخة الفردية 01. يفترض النموذج أن OCM Servers وProtocol Servers المقترنة وأي Token Server مفوض غير مخترقة وتطبق السياسة المحلية كما ينبغي. التوقيع وTLS يحميان من العبث في قناة الاتصال؛ ولا يجعلان الطرف الموثوق المخترق سليماً.

ثلاثة أوضاع وثلاثة حدود للإلغاء

في الوضع المجهز مسبقاً يرسل OCM Server معلومات المشاركة قبل الوصول عبر قناة خلفية موقعة. يخزن Protocol Server سجل Share، ثم يتلقى طلب إلغاء عند انتهاء المشاركة كي يوقف الخدمة ويحرر الموارد. وهو الوضع الوحيد المحدد لـSSH، والأنسب للتطبيقات التي تنشئ جلسة أو مورداً خاصاً بكل مشاركة.

في الوضع المكتفي بذاته لا توجد واجهة خلفية لكل مشاركة. تحمل مطالبة ocm_ip داخل JWT موقع كل ما يحتاجه Protocol Server للترخيص، فلا يحتفظ بحالة للمشاركة. لكن الرمز الصادر لا يمكن سحبه قبل انتهاء مدته. لذلك تمنع المسودة مزج هذا المسار بالوضع المجهز للمشاركة نفسها، حتى لا يظل رمز قديم نافذاً بعد إزالة السجل.

أما الوضع القائم على الاستعلام فيتحقق من الاعتماد عبر نقطة وفق RFC 7662. يحافظ ذلك على التوافق مع خوادم مستقبلة ما زالت تقدم sharedSecret القديم مباشرة، لكنه يعيد الاعتماد لكل طلب غير مخزن على OCM Server أو Token Server. كما يؤخر تخزين نتيجة إيجابية ظهور أثر الإلغاء حتى انتهاء مدة التخزين.

لهذا لا تكفي عبارة «يدعم OCM-IP». فالخيار يحدد موضع الحالة، والخادم الذي يجب أن يظل متاحاً، والبيانات التي تنتقل، واللحظة التي يصبح فيها إيقاف المشاركة حقيقة تشغيلية.

الشفافية هنا خاصية للطرف المستقبل

ينص شرط الشفافية على ألا يطلب من الخادم المستقبل تنفيذ OCM-IP أو حتى العلم به. قد تنتهي نقطة الوصول المعلنة عند OCM Server أو reverse proxy أو Protocol Server على مضيف آخر. ولا توجد قدرة في طبقة OCM يستطيع النظير البعيد استخدامها لكشف التركيب.

داخل نطاق الإرسال، العلاقة مقصودة ومحددة. ينفذ المشغلون الاقتران خارج البروتوكول، ويضبطون البروتوكولات وأنواع الموارد والأوضاع والنطاقات ونقاط الاتصال وعناوين JWKS. ويتعين على Protocol Server الاحتفاظ بقائمة مسموح بها لنطاقات OCM المقترنة ورفض أي جهة إصدار غير مقترنة.

تستخدم القناة الخلفية HTTP Message Signatures ومجموعات JWK المنشورة، بينما تعتمد واجهة الوصول على JWT موقع. يربط التحقق الادعاء بمفتاح، ثم يربط الاقتران وحالة المشاركة ذلك الادعاء بسلطة محدودة.

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

ocm_ip لم يسجل بعد لدى IANA

تطلب المسودة تسجيل ocm_ip بوصفه مطالبة JWT وعضواً في استجابة استعلام OAuth عندما تصبح الوثيقة RFC. لم يتضمن سجل JWT لدى IANA ولا سجلات معاملات OAuth هذا الاسم المطابق عند وقت الفحص.

هذا هو الفصل الطبيعي بين تطوير الوثيقة وتنفيذ طلباتها. تبني مجموعة العمل لا ينفذ قسم IANA Considerations. وعلى التجارب أن تسمي نسخة المسودة، وألا تعرض الاسم المطلوب باعتباره قيمة معيارية مخصصة بالفعل.

خريطة مسؤولية تبقى لدى من فوض

يقترح Daniel Kade خريطة لمسؤولية التفويض تخضع للتحكم في الوصول. تربط الخريطة OCM Server وProtocol Server وToken Server بالوظيفة والبروتوكولات والموارد المسندة، والوضع المختار، ومعرفات نقطة الاتصال والمفتاح، وفترة النفاذ، والشخص أو العملية التي أجازت التغيير، ونتيجة الإلغاء وتحرير الموارد، وجهة اتصال الحوادث، ومكان حفظ الأدلة.

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

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

يتفق ذلك مع The Policy Mirror لدى Heng Lu: الفاعل والقاعدة والدليل أشياء مختلفة لا يتحدث أحدها باسم الآخر. وتسمح Minimum Initial Specification ببقاء النواة المشتركة صغيرة مع حفظ سجل محلي أغنى. يمكن للطرف المستقبل أن يحصل على واجهة مستقرة، وللمشغل أن يحتفظ بتاريخ ما وراءها.

المصادر

1. بروتوكول تكامل OCM، نسخة WG 00
2. السجل الحالي في Datatracker
3. تاريخ الوثيقة
4. رسالة نتيجة التبني
5. النسخة الفردية السابقة 01
6. مجموعة عمل Open Cloud Mesh
7. محضر OCM في IETF 126
8. بروتوكول OCM الأساسي، نسخة WG 06
9. RFC 9421 — توقيعات رسائل HTTP
10. RFC 7517 — JSON Web Key
11. RFC 7662 — استعلام رموز OAuth 2.0
12. RFC 7519 — JSON Web Token
13. سجل JWT لدى IANA
14. سجلات OAuth لدى IANA
15. Heng Lu — The Policy Mirror
16. Heng Lu — Minimum Initial Specification