إيصال واحد لدفعة أحداث أمنية لا يثبت إغلاق كل حالة

الخلاصة

• النسخة 03 من draft-deshpande-secevent-http-multi-set-push في مرحلة IESG Last Call حتى 23 سبتمبر 2026. وهي مسودة إنترنت فردية في مجال الأمن تستهدف مرتبة Proposed Standard، ولم تصبح RFC معتمداً.
• يستطيع مرسل واحد وضع عدة Security Event Tokens في طلب HTTPS POST. يرد المستقبل على معرّف jti لكل رمز ضمن ack أو setErrs؛ وهذا يخص الاستلام والتحليل والتحقق، لا تعليق الحساب أو إبطال الاعتماد في نظام لاحق.
• التدقيق المجدي يفصل زمن النقل عن حفظ الحدث، ومطابقة الهوية، والقرار المحلي، والتنفيذ، ورصد النتيجة. لا يكفي الرمز 202 لإثبات اكتمال هذه السلسلة.

ستة رموز، وستة ملفات متابعة

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

يأتي المشروع بعد RFC 8935، الذي يحدد دفع رمز SET واحد في طلب HTTPS. عندما تتكدس أحداث موجهة إلى المستقبل نفسه، تصبح الطلبات الفردية مكلفة وقد تصطدم بحدود المعدل. لذلك تحمل رسالة application/secevents+json كائناً اسمه sets تُفهرس فيه الرموز بمعرّفات jti، وتعيد الاستجابة قائمة ack وأخطاء setErrs الخاصة بالرموز. يذكر سجل IETF أن النص لا يزال في Last Call في 21 سبتمبر. لا يستنتج من ذلك اعتماد نهائي، أو انتشار تنفيذي، أو نجاح تعطيل حسابات في الواقع.

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

وقد تشير الاستجابة إلى طلب سابق لا إلى الدفعة الحالية. يسمح sets الفارغ بطلب الإقرارات المتأخرة، ويمكن أن تضم الاستجابة معرّفات من عمليات إرسال أقدم. يجب الربط بواسطة jti لا بواسطة حالة آخر POST. بعد الإقرار، لا يلزم المرسل الاحتفاظ بنسخة لإعادة الإرسال؛ يصبح الحفظ اللازم للموثوقية من مسؤولية المستقبل. هنا تنتقل حيازة الدليل، بينما لا تفرض المسودة سجلاً موحداً لنتائج القرارات المحلية.

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

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

أما RFC 9967 فيتناول ربط طلب SCIM غير المتزامن بحدث لاحق، وهي مسألة أخرى. لا هذا الربط ولا إقرار multi-SET يثبت أن قرار الإيقاف أو الإبطال اتخذ ونُفذ لدى الطرف الآخر.

المصادر

حالة المسودة لدى IETF؛ نص النسخة 03؛ RFC 8935؛ RFC 8417؛ RFC 9967.