الخلاصة

  • صدرت النسخة -01 من مسودة إثبات حالة المحفظة في 27 سبتمبر 2026 بوصفها Internet-Draft فردية؛ ليست RFC ولا دليلاً على اعتماد IETF أو انتشار الخدمة.
  • تشمل بيانات JSON الموقعة على المستوى الأعلى id وpass وresults وattestedAt. وقد يظهر العنوان داخل شرط معيّن، لكن الصيغة لا تضمن تسمية المحفظة في كل رد.
  • يُرسل expiresAt خارج التوقيع في JSON. أما JWT الاختياري فيوقّع sub وexp على حدة، ولا يجوز الاكتفاء بالتحقق من JSON لاستعمال ادعاءاته.

من احتفظ بالسؤال الأصلي؟

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

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

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

وقت الملاحظة ليس تاريخ الانتهاء المعروض

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

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

وثيقتان موقعتان لا تصبحان وثيقة واحدة

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

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

أضافت النسخة -01 خيار توقيع JSON مفصول المجال، وتوقيعاً مرافقاً اختيارياً، وتفرعات رفض أوضح. لكنها لا تقول إنها اخترعت أصل الفكرة؛ يذكر سجل التغييرات أن توقيعات النسخة -00 تبقى قابلة للتحقق. الجديد هنا توضيح الحدود وإجراءات التعامل معها، لا اكتشاف حادثة. وتبين صفحة Datatracker أنها مسودة فردية نشطة بلا مسار RFC، وحالتها لدى IESG هي I-D Exists. إيداعها عبر IETF ليس مصادقة من المنظمة، وإشارات المؤلف إلى مشروعات أو جهات إصدار مستخدمة لا تثبت وحدها انتشاراً مستقلاً.

المصادر