الخلاصة
- أضافت المراجعة 01 من
draft-kuehlewind-audit-architecture، المؤرخة في 7 سبتمبر 2026، تخزين السجلات داخل مسار الاتصال: يستطيع كل وكيل تشغيل Audit Store خاص به وإرسال السجلات عبر الوصلة المستخدمة في التفاعل نفسه. - تصف المسودة هذا الترتيب بأنه بديل للمخزن الخارجي لا بديلاً يلغي وجوده، وتسمح بالجمع بين الطريقتين. كما تقر بأن تشغيل الوكيل والمخزن لدى الجهة نفسها يضع ثقة أكبر في تلك الجهة.
- التخزين ليس وظيفة التدقيق كلها. فالنص يفصل بين المسجّل، وAuditing Service، والإثبات، والتسجيل في خدمة شفافية، والمدقق، والمتحقق.
- ما زالت الوثيقة مسودة إنترنت فردية. ويوضح Datatracker أنها غير معتمدة من IETF ولا تتمتع بمكانة رسمية في مسار وضع المعايير.
- يقترح Daniel Kade «إيصالاً لطوبولوجيا الحيازة» يحدد مشغّل كل وظيفة. وهذا تحليل تحريري، لا متطلب وارد في المسودة.
اختصار جديد يحمل تحذيره الخاص
أهم إضافة في المراجعة 01 فقرة واحدة. تقول الفقرة الجديدة 3.2 إن السجلات لا يلزم أن تُصدّر كلها إلى Audit Store خارجي ومنفصل. بل يمكن لكل وكيل تشغيل مخزنه، ثم إرسال سجلاته إلى مخزن الوكيل الذي يتعامل معه، مستفيداً من قناة النقل القائمة بدلاً من إنشاء قناة مستقلة خارج المسار.
لهذا الخيار فائدة تشغيلية واضحة. فالوكيل قصير العمر قد يكون قد أنشأ بالفعل اتصالاً موثقاً مع الطرف المقابل. وإعادة استخدامه تقلل التكاملات الإضافية وتسمح للسجل بأن يتبع سير العمل الموزع. ولا تعرض المسودة التخزين الذاتي باعتباره الجواب الوحيد؛ بل تسميه بديلاً للمخزن الخارجي، وتجيز استخدام الاثنين معاً، ثم تصرّح بثمن الثقة: حين تشغّل الجهة نفسها الوكيل وAudit Store، يعتمد النظام عليها بدرجة أكبر مما يعتمد على مخزن خارجي مستقل.
هذه الفقرة غير موجودة في المراجعة 00 الصادرة في مايو. ومن ثم فإن الخبر يتعلق بتغيير يمكن التحقق منه بين نسختين، لا بإعادة صياغة تحليل قديم.
كلمة «تدقيق» تخفي وظائف متعددة
ليست المشكلة أن التخزين داخل مسار الاتصال باطل بطبيعته. المشكلة تبدأ حين تختصر جهة النشر سلسلة من الأفعال في عبارة مطمئنة مثل «الوكيل خاضع للتدقيق». والمراجعة 01 نفسها توفر المفردات اللازمة لتجنب ذلك الاختزال.
ينشئ المشاركون الرئيسيون سجلات من مواقع رؤية مختلفة. تستطيع واجهة المستخدم حفظ القصد والموافقات. ويستطيع الوكيل إصدار إشارات عن الأفعال والتفويض وانتقالات الصلاحية. أما الأداة أو الخدمة الخارجية فتسجل الطلب كما رأته عند النقطة التي وقع فيها الأثر. يلتقط Audit Recorder هذه الإشارات أو يحولها. ويحفظ Audit Store السجلات ويتيح استرجاعها. وتقوم Auditing Service بتوحيد صورتها، وتوقيعها بهوية تخصها، ثم تقديمها للتسجيل في سجل شفافية. بعد ذلك يقيّم المدقق الأدلة بموجب سياسة محددة، ويمكن للمتحقق فحص ادعاءات بعينها.
كل وظيفة تجيب عن سؤال مختلف. يحدد التخزين مكان العثور على السجل لاحقاً. ويربط التوقيع بياناً بمفتاح. وقد يدعم الإثبات ادعاءً يتعلق ببيئة إنتاج السجل. ويساعد إيصال الشفافية على إثبات أن بياناً سُجل في وقت معين وعلى كشف بعض العروض المتعارضة للتاريخ. أما استقلال المدقق فيتعلق بمن يصدر الحكم. ولا يثبت أي عنصر منفرد أن كل طرف سجل كل واقعة بصدق ومن دون حذف.
وتزداد أهمية هذا الفصل لأن المسودة تسمح بتجميع الأدوار. فالدور وظيفة وليس بالضرورة وحدة نشر أو شركة مستقلة، وقد تؤدي الجهة الواحدة أدواراً عدة. ويمكن للعملية التي تستضيف الوكيل أن تنفذ أيضاً دور Recorder. هذا يبسط التشغيل، لكن النص يذكر خطر التواطؤ بين الوكيل والمسجّل، ويشير إلى مسجّل مستقل أو إلى منع الإنكار عبر التسجيل الشفاف بوصفهما مسارين للتخفيف. وفي موضع آخر تقول المراجعة 01 إن خصائص المساءلة في البنية تتطلب Auditing Service مستقلة.
لا يوجد تناقض إذا بقيت الحدود واضحة. فقد يتولى مخزن تابع للجهة نفسها النقل والحفظ، بينما تتولى خدمة مستقلة توحيد السجلات أو تثبيتها خارجياً. وقد يستضيف طرف ثالث المخزن من دون أن يكون هو من يصدر حكم التدقيق. وفي المقابل، قد يبقى منتج «خارجي» تحت سيطرة المجموعة التجارية أو المسؤول أو حافظ المفاتيح نفسه. كلمة «خارجي» تصف الموقع، أما «مستقل» فتصف السيطرة والحوافز.
عنوان المخزن لا يثبت سلسلة الحيازة
لنقارن ترتيبين. في الأول، يكتب الوكيل في Store داخل عمليته، لكن خدمة منفصلة تسجل فوراً التزامات موقعة في نظام شفافية لا يستطيع مشغّل الوكيل إعادة كتابته منفرداً. وفي الثاني، يصدّر الوكيل أحداثه إلى حساب سجلات سحابي تديره المجموعة نفسها التي تشغّل الوكيل، وتستطيع تعديل الأصل والنسخة قبل ظهور أي التزام خارجي.
المخزن الثاني خارجي جغرافياً. ومع ذلك قد يفرض الترتيب الأول قيداً تاريخياً أقوى وفي وقت أبكر. ولا يثبت المثال اكتمال أي من الترتيبين أو امتثاله، لكنه يوضح أن رسم الشبكة وعدد الموردين لا يقومان مقام سجل الحيازة.
تفصل RFC 9334 الوظائف بصورة مشابهة في الإثبات عن بُعد: ينتج Attester الأدلة، ويقيّمها Verifier، ثم يطبق Relying Party سياسته الخاصة على النتيجة. كما تفصل RFC 9943 بين البيانات الموقعة وخدمات الشفافية والإيصالات وقرارات الأطراف المعتمدة عليها. اسم المكوّن لا يصنع مستوى الضمان؛ بل تحدده الأدوار والسياسات والمفاتيح ومسار الدليل.
ويجب ألا تضيع الحالة المؤسسية للوثيقة. لا تعرض صفحة Datatracker مسار RFC أو مدير مجال مسؤولاً أو تبنياً من فريق عمل، وتضع تحذيراً صريحاً بأن مسودة الإنترنت الفردية لا تمثل اعتماد IETF. خيار التخزين الجديد اقتراح قيد التطوير، وليس قاعدة أصدرتها IETF لأنظمة الوكلاء.
المصادر
- سجل الوثيقة في IETF Datatracker
- بنية تدقيق الوكلاء، المراجعة 01
- بنية تدقيق الوكلاء، المراجعة 00
- مقارنة IETF author-tools بين المراجعتين 00 و01
- RFC 9334: بنية RATS
- RFC 9943: بنية SCITT
- Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu: Running Code Primary
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

