الخلاصة

  • يسجل Datatracker طلب AUDIT BoF في حالة Declined. أما قائمة non-WG التي أُنشئت في 31 أغسطس/آب 2026 فتتيح مراجعة طلب محتمل وميثاق مقترح، ولا تنشئ Working Group.
  • لم يقل IESG إن تدقيق أفعال الوكلاء عديم القيمة؛ بل رأى أن النطاق الحالي واسع أكثر من اللازم، وطلب بياناً أدق لما لا تغطيه OAuth وWIMSE وOpenTelemetry والأعمال المجاورة.
  • تميز المسودة الفردية بين سجلات التفاعل والفعل والتفويض وانتقال الصلاحية، لكنها تقر بأنها لا تحل رفض الخدمة للتسجيل أو تواطؤ جميع الأطراف أو مواءمة النموذج، وأن نموذج التهديد التفصيلي لم يكتمل.
  • ينبغي لسجل علني لحالة السلطة أن يفصل بين ساحة النقاش وقرار BoF والميثاق وتبني المسودة ومراجعة IETF ونشر RFC والتشغيل، حتى لا تتحول المشاركة إلى تفويض بالوصف وحده.

ما تغير هو مكان النقاش

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

تصف صفحة طلب AUDIT BoF، النسخة 02 السجل بأنه “Declined BOF request” وتعرض الحالة “Declined”، وهو التصنيف نفسه الظاهر في فهرس طلبات BoF. يعود آخر تحديث إلى 6 يوليو/تموز، ولا تسمي البيانات قيادة مسؤولة. يذكر نص المقترح مديري Security Area بوصفهم ADs مقترحين، ويقترح Yaroslav Rosomakho رئيساً، لكن الاسم المقترح ليس تعييناً.

وتضع القائمة الجديدة حدودها بوضوح. يقول فهرس قوائم non-WG إن الغرض من audit هو مناقشة BoF محتمل، وتحديث ميثاق مقترح، والعمل نحو تشكيل WG جديد. وفي تاريخ القطع لا يتضمن الأرشيف العام إلا إعلان الإنشاء. الأفعال كلها مستقبلية: هناك طريق محتمل إلى تفويض، لا تفويض مضمر داخل عنوان البريد.

تنسجم هذه الخطوة مع إرشادات قوائم non-WG، فهي تسمح بقوائم يُقصد منها الوصول إلى WG، ويوافق Area Director المختص على طلب إنشائها. نطاق تلك الموافقة هو وسيلة الاتصال. ولا تمنح تلقائياً BoF أو ميثاقاً أو milestones أو chairs.

يوضح RFC 2418 الفارق المؤسسي. يقوم Working Group على ميثاق ضيق وقيادة مسؤولة وإجراءات ومعالم محددة. ومن خصائصه أن له قائمة بريدية. لكن الاستدلال لا يعمل بالعكس: ليست كل قائمة فريق عمل، مثلما أن فتح باب قاعة لا يفوض الحاضرين بالتوقيع باسم المؤسسة.

«Deferred» في رسالة يونيو و«Declined» في السجل الحالي

استخدم رد IESG في 3 يونيو/حزيران كلمة “deferred”، وقد حفظه أصحاب المقترح داخل ردهم المؤرخ 5 يونيو. لم يرفض الرد فكرة تدقيق أفعال الوكلاء؛ وصف المفهوم بأنه جيد، ثم اعتبر الطلب الحالي واسعاً. ودعا إلى تضييق النطاق والتشاور مع OAuth وWIMSE وشرح سبب عجز العمل القائم أو profile لـOpenTelemetry عن سد الفجوة. كما تساءل عما إذا كانت بعض مفاهيم النية والسياسة أنسب لإطار قانوني من عمارة بروتوكولية في IETF.

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

لا حاجة إلى جعل الكلمتين مترادفتين. تصف “deferred” لغة التخاطب في يونيو، بينما تصف “Declined” الحالة المعروضة الآن في Datatracker. يحتفظ سجل سليم بالكلمتين وتاريخهما ومصدرهما والجهة صاحبة القرار. ويمكن لطلب منقح أن ينشئ حالة أخرى مستقبلاً. رفض الطلب القائم لا يعني أن الموضوع محظور إلى الأبد.

هذه الدقة تعالج قفزة أوسع شرحها Heng Lu في مقاله عن سراب نموذج أصحاب المصلحة المتعددين: الحضور والمشاركة لا يكشفان وحدهما عن الأصيل الذي يمنح التوكيل. ووجود نقاش في IETF لا يعني أن IETF اعتمدت ما يُناقش أو فوضت المشاركين تمثيلها.

أربع عائلات من الأدلة لا سجل واحد مطلق

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

تقسم المسودة المادة إلى أربع فئات. تحفظ Interaction Records الطلبات والموافقات وغيرها من أدلة النية في واجهة المستخدم. وتسجل Action Records ما وقع عند حد التنفيذ. وتبين Delegation Records السلطة المنقولة ونطاقها وقيودها. أما Authorization Transition Records فتسجل المنح الأولي والموافقة الإضافية والتضييق والإلغاء والانتهاء.

يمكن لسياق تدقيق مشترك أن يحمل معرفات الربط وإشارات إلى أحداث سابقة. وينتج كل طرف سجله من منظوره، ثم يعمل audit store موثوق به جزئياً على التطبيع والعرض للمدقق. وقد تدعم خدمات attestation وtransparency بعض الأدلة اختيارياً. قيمة التقسيم أنه يمنع دمج ثلاث جمل مختلفة: «طلب المستخدم»، و«كان النظام مخولاً»، و«حدث الفعل».

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

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

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

كل معيار مجاور يثبت شيئاً أضيق

طلب IESG تحليلاً أقوى للتداخل ليس عائقاً إجرائياً؛ إنه وسيلة لمنع المظلة الجديدة من إعادة تعريف أعمال ناضجة وترك الفجوات الحقيقية بلا مالك.

يستطيع RFC 8693 الخاص بـOAuth Token Exchange تمثيل التفويض وسلسلة actors خلال تبادل الرموز. يفيد ذلك في وصف السلطة المنقولة، لكنه لا يقدم وحده تعليمات المستخدم الأولى وكل انتقالات الصلاحية والنتيجة وحكم المدقق. كما يترك البروتوكول الأساسي دلالات الرموز التفصيلية وخصائص الأمان ونماذج الثقة خارج نطاقه.

تنشر توصية W3C Trace Context معرفات تربط أجزاء طلب موزع. يثبت الربط أن أحداثاً تنتمي إلى تدفق واحد، لا أن الفاعل كان مخولاً أو أن التفويض ضُيق أو أن المستخدم وافق. trace ID خيط للملاحظة وليس سند سلطة.

ينظم RFC 9334 ومعمارية RATS Evidence وVerifier وAttestation Result ثم تطبيق Relying Party للسياسة. ينفع ذلك لتقييم مكون أو بيئة تنفيذ، لكنه لا ينشئ سلطة قانونية ولا يثبت الوفاء الدلالي بقصد الإنسان. قد ينفذ جهاز سليم أمراً غير مأذون على أكمل وجه.

ويصف RFC 9943 ومعمارية SCITT statements موقعة وخدمات شفافية append-only وإيصالات تسجيل أو inclusion. تجعل هذه الآليات الحذف أو التعديل اللاحق أكثر قابلية للكشف، لكنها لا تجعل القول صحيحاً ولا تثبت اكتمال الأحداث ولا تحول النزاهة التشفيرية إلى إذن.

ينبغي إذاً أن يرسم النطاق مسؤوليات واضحة: ما يبقى في OAuth وWIMSE وTrace Context وRATS وSCITT وHTTP، وما هي الوصلة العابرة للنطاقات التي لا يملكها أحد. كثرة الاختصارات لا تمنح AUDIT وظيفة؛ تحديد الباقي وحدوده هو الذي يفعل.

المؤسسة التي تصمم سجلات السلطة تحتاج سجلاً لسلطتها

يريد الاقتراح التقني الإجابة عن «من أذن بفعل الوكيل؟». وعلى السجل المؤسسي أن يجيب بالتوازي عن «من أذن بكل مرحلة من مراحل التقييس؟». الخطأ واحد في الحالتين: اعتبار وجود record دليلاً على السلطة التي يفترض أن يصفها.

يمكن أن يبدأ authority-state receipt بهوية ثابتة للمشكلة ونسخة دقيقة من المقترح. ويسجل الحالة—proposal، أو BoF deferred/declined، أو non-WG discussion، أو BoF approved، أو chartering، أو active WG، أو concluded—ثم يسمي الجهة المختصة بخلق تلك الحالة. ويضم تاريخ القرار ورابطه ولفظه الدقيق من دون تضخيم.

وتحمل كل مراجعة scope delta: ماذا حُذف؟ ما الذي أسند إلى مجموعات مجاورة؟ وما الذي بقي؟ يظل AD أو chair «مقترحاً» إلى أن يُعين. وللساحة حقل منفصل عن السلطة. يحمل الميثاق نسخة وتاريخ اعتماد، أو تكون قيمته null. وتفرق هوية الوثيقة بين individual وWG-adopted مع سجل التبني.

كما يجب فصل WG Last Call عن IETF Last Call وعن IESG evaluation والاعتراضات غير المحسومة. وتذكر خانة النشر Internet-Draft أو stream وفئة RFC بدلاً من كلمة “standard” العامة. أما التنفيذ ومالك السياسة فلهما خانة deployment. نشر RFC لا يثبت التشغيل، وتشغيل draft لا يصنع إجماعاً.

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

سجل AUDIT الحالي موجز: توجد مسودات فردية؛ عولج طلب BoF version 02 وتلقى نقداً للنطاق؛ حالته في Datatracker هي Declined؛ توجد قائمة non-WG لصياغة BoF وميثاق محتملين؛ ولا توجد قيادة مسؤولة معينة أو charter معتمد أو WG أو تبنٍّ أو إجماع IETF.

لا حق تلقائياً في المراقبة باسم المساءلة

ينبغي لأي نطاق جديد أن يحدد تقليل البيانات لكل نوع سجل. يمكن إبقاء المحتوى خارج النطاق الآخر واستخدام detached payloads أو hashes أو كشف انتقائي. وينبغي تفضيل معرفات pairwise أو opaque عندما لا توجد حاجة مأذونة للربط العالمي. القدرة على الربط ليست الإذن بالربط.

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

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