الخلاصة

  • تتيح النسخة الفردية الأولى من مسودة AAuth Events، المؤرخة في 28 سبتمبر 2026، للمورد إرسال حدث موقّع إلى Agent Provider أو AP بعد وجود اشتراك صالح للوكيل.
  • لا يجوز للوسيط أن يرد برمز HTTP 202 قبل تسجيل الحدث المقبول تسجيلًا دائمًا؛ وهذا إقرار بالحفظ عند الوسيط، لا شهادة بأن الوكيل استلم الحدث أو تحقّق منه أو تصرّف قبل انتهاء صلاحيته.

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

نشر Dick Hardt النسخة -00 في 28 سبتمبر 2026 باعتبارها Internet-Draft فردية تقصد مسار Standards Track مستقبلًا. تظهر المسودة في سجل IETF Datatracker بوصفها مسودة قائمة عند المراجعة، لا RFC معتمدة ولا إثباتًا لاعتماد جماعي أو انتشار فعلي. وهي امتداد لمسودة بروتوكول AAuth منفصلة، صممت لتمكين الوكلاء من استخدام الموارد نيابة عن أشخاص. المشكلة الجديدة ليست مصادقة الطلب الأصلي، بل كيف يبلغ المورد الوكيل بتغير لاحق بينما قد يكون الوكيل غير متصل ولا يملك عنوانًا عامًا لاستقبال الإشعارات.

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

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

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

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

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

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

المصادر