الخلاصة

  • تجمع المراجعة 01 من Authenticated Provenance for WIMSE Delegation Chains بين استمرارية الملخصات وتوقيع مجمع؛ الأولى تكشف أين تغير المحتوى، والثاني يمنع حذف موقّع مرّر المحتوى كما هو دون أن يفشل التحقق.
  • الذي يقترب من الحجم الثابت هو قيمة التوقيع المجمع وحدها. أما WIT ومدخل Signature-Input والمسار والاستعلام وملخصا الدخول والخروج فتزداد مع كل قفزة.
  • يثبت التحقق الناجح المشاركين المعروضين وينسب التحولات الموقعة إليهم، لكنه لا يثبت اكتمال المسار المتوقع أو مشروعية التغيير أو صحته أو تنفيذ العملية ونتيجتها.

ختم واحد لا يحمل ذاكرته في داخله

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

يقترح draft-reddy-wimse-aggregate-signatures-01 طريقة لإثبات ذلك التسلسل. نُشرت المراجعة 01 في 28 سبتمبر 2026 بوصفها Internet-Draft فردية نشطة ذات حالة مستهدفة Standards Track. ليست RFC، ولا وثيقة لفريق عمل WIMSE، ولا إجماعاً من IETF، ولا تقرير تطبيق أو دليلاً على التبني. قد تتغير أو تُستبدل أو تنتهي صلاحيتها.

يتكون التصميم من آليتين لا من حقل واحد. في الآلية الأولى، يوقع كل عبء عمل العلاقة بين ما استلمه وما أرسله. يحمل wimse-req-digest ملخص جسم الطلب الداخل، بينما يمثل Content-Digest الجسم الخارج. يبدأ المنشئ بالقيمة المحجوزة origin. ثم يقارن المدقق مخرج كل قفزة بالمدخل الموقع للقفزة التالية.

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

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

الآلية الثانية هي Signature-Aggregate. ينشئ كل عبء توقيعاً على قاعدة توقيعه، ثم تدمج القيم الفردية في قيمة تراكمية واحدة. يتحقق المستقبل من هذه القيمة مقابل قائمة مرتبة من أزواج المفتاح العام والرسالة المعاد بناؤها لكل موقّع.

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

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

ما الذي يزداد فعلياً

توضح المراجعة 01 أن حجم التوقيع المجمع يبقى قريباً من حجم توقيع واحد، بينما تكبر Signature-Input وWorkload-Identity-Tokens والملخصات مع طول السلسلة.

يحتاج المدقق لكل قفزة إلى تسمية فريدة ومدخل يحدد المكونات المشمولة، ومعلمات الإنشاء والانتهاء وnonce وtag وaudience، ورمز هوية عبء العمل، وملخص الدخول، وقيم wimse-req-path وwimse-req-query المحفوظة، وملخص الخروج، وترتيب يربط السجل بجاريه.

تعرّف المراجعة قاموس Structured Fields باسم Workload-Identity-Tokens، ومفتاح كل عضو هو تسمية التوقيع الخاصة بالقفزة. على العبء الجديد أن يحتفظ بالأعضاء السابقين ويتحقق منهم ويختار تسمية جديدة ويغطي عضوه بتوقيعه. يؤدي استبدال WIT سابق أو حذفه إلى تغيير قيمة موقعة.

يعطي WIT هوية sub والمفتاح العام في cnf.jwk. لكن وجود الرمز ليس نتيجة تحقق. ما زال على المستقبل فحص الجهة المصدرة والجمهور والصلاحية وربط المفتاح ونطاق الثقة وسياسة الخوارزمية قبل معالجة الرسالة. الرمز المحمول ادعاء يمكن اختباره، لا تفويضاً ذاتياً.

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

يُستمد ملخص خروج القفزة من ملخص الدخول الموقع لدى خليفتها. أما القفزة الأخيرة فلا خليفة لها، فيؤخذ خروجها من Content-Digest النهائي. وتُقرأ الطريقة ونوع المحتوى من الرسالة النهائية لأن التصميم يمنع تغييرهما عبر القفزات؛ التغيير يجعل إعادة بناء التواقيع السابقة تفشل.

يمكن تلخيص شكل الإثبات هكذا: قيمة مجمعة S، ثم مجموع مواد كل قفزة: WIT ومدخل التوقيع والملخصات وقيم إعادة البناء، أي S + Σ(W + I + D + R). هذه صيغة تفسيرية وضعها Daniel Kade وليست قياس أداء. يختلف الحجم الحقيقي باختلاف طول الرموز والمسارات والخوارزميات والتسميات والترميز وضغط الرؤوس.

الحكم الجماعي لا يحدد القفزة المعيبة

يعطي التوقيع المجمع نتيجة واحدة: إما أن تتطابق كل المساهمات مع قائمة المفاتيح والرسائل، وإما أن يفشل المجموع. مساهمة فاسدة واحدة تكفي لإسقاط السلسلة كلها، ولا تحدد القيمة المجردة أي قفزة كانت السبب.

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

وتوجد حدود مماثلة في اختيار الخوارزمية. تحتاج كل القفزات إلى خوارزمية قابلة للتجميع ومتوافقة. تشير المراجعة إلى مخطط BLS message augmentation كخيار يمكن أن يجسد التصميم حالياً، لكنها تترك معرّف الخوارزمية في WIT لمواصفة أخرى. BLS ليس مقاوماً للحوسبة الكمية. نجاح الحساب لا يلغي قائمة السماح أو سياسة نطاق الثقة أو دفاعات خفض المستوى.

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

عودة الرسالة ليست إيصال النتيجة

يمكن حماية الاستجابة في الاتجاه العكسي. يستخدم منشئها wimse-resp-digest="origin"، ثم يسجل كل وسيط ما تلقاه وما أعاد إرساله ويضيف توقيعه إلى المجموع. إذا عادت استجابة غير موقعة، فلا تضمن هذه الآلية اكتشاف حذفها أو تعديلها.

حتى الاستجابة الموقعة لا تثبت أن الأصل المالي انتقل أو أن السجل حُفظ أو أن الصلاحية مُنحت. تثبت من قال ماذا عبر السلسلة. يحتاج commit التطبيق والنتيجة الخارجية إلى إيصال آخر وملاحظة مستقلة.

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

المصادر

جُمّدت المصادر في 30 سبتمبر 2026 بتوقيت Asia/Shanghai. لا تقدم قياساً للحمل أو تطبيقاً متوافقاً بين جهات متعددة أو هجوماً واقعياً أو وفراً إنتاجياً أو نتيجة امتثال أو خسارة مرصودة. لا تفترض هذه المقالة عبئاً خبيثاً بعينه ولا تحول مقترحاً فردياً إلى ممارسة منشورة.