الخلاصة

  • تقترح draft-nikolaichuk-scitt-continuity-receipts-01 بياناً موقعاً عن استعادة أصل ذي حالة، وإيصالاً وفق RFC 9942 يثبت تسجيل ذلك البيان في خدمة شفافية محددة.
  • يمكن حفظ Attestation Results كمرجع أو تضمينها أو تسجيلها بصورة مستقلة. المرجع يقلل الإفصاح، لكنه يفقد قيمته التشغيلية إذا لم تبق البايتات ذاتها قابلة للاسترجاع.
  • قبول HTTP 202 مع entry identifier ليس Receipt. وحتى بعد صدور Receipt، فإنه يشهد تسجيل ادعاء ولا يثبت وقوع الاستعادة أو صلاحية التصديق أو وفاء الأصل الناتج.

أثر باقٍ وسنده غائب

تحتفظ المؤسسة ببيان الاستعادة وبإيصال إدراجه في سجل append-only. التوقيعات سليمة، وموضع الورقة في الشجرة قابل للتحقق. لكن حقل التصديق لا يحمل النتيجة نفسها؛ يحمل digest يشير إلى مستودع لم يعد متاحاً.

ما بقي صحيحاً هو أن جهة معينة سجلت ادعاءً معيناً. وما ضاع هو قدرة الطرف المعتمد على فحص الأساس الذي أعطى حالة بيئة الاستعادة معناها. لا يفسد Receipt بسبب ذلك، لكنه يصبح دليلاً على طبقة أضيق مما قد توحي به شاشة «verified».

هذه المسافة هي إحدى نقاط القوة في draft-nikolaichuk-scitt-continuity-receipts-01 المؤرخة 29 سبتمبر 2026. الوثيقة Internet-Draft فردية بحالة مقصودة Informational؛ ليست وثيقة اعتمدتها مجموعة SCITT ولا RFC. وهي لا تنشئ تنسيق تصديق جديداً أو خدمة شفافية جديدة. إنها تحدد payload لبيان استعادة يستخدم البنية القائمة في RFC 9943 وإيصالات RFC 9942.

لكل خطوة صاحب معرفة مختلف

يبدأ المسار داخل بيئة الاستعادة. ينتج Attester أدلة Evidence، ثم يقيمها Verifier ويصدر Attestation Results. تقرر آلية أخرى تحرير مادة المفتاح المختومة. تفك البيئة التشفير، وتعيد بناء الأصل، وتحسب recovered-digest من plaintext الناتج فعلاً.

بعد ذلك تبني Recovery Authority claims وتوقع Recovery Statement، مستخدمة معرف الأصل الثابت بوصفه subject. تطبق Transparency Service سياسة التسجيل وتضيف البيان إلى سجلها وتصدر Receipt. وفي النهاية يفحص Relying Party الإيصال وهوية Issuer والـ claims ومراجع التصديق وسياسته الخاصة قبل الفعل.

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

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

ما يثبته الإيصال تحديداً

يثبت Continuity Receipt أن Recovery Statement معينة، وقعها Issuer معين، سُجلت لدى Transparency Service معينة في موضع معين من سجلها append-only، وأن الخدمة وقعت إثبات هذه الحقيقة.

لا يثبت أن Recovery Event وقع. لا يثبت أن البايتات المستعادة تطابق الأصل. لا يثبت أن Attestation Results المشار إليها تحققت أو كانت favourable. لا يؤكد أن البيئة كانت في الحالة الموصوفة. ولا يبين أن Registration Policy اختبرت أياً من ذلك.

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

لهذا يحتاج العرض إلى ثلاث خانات واضحة: asserted لما قاله Issuer، established لما أثبته فحص مستقل، وunverifiable لما تعذر فحصه. ضغطها إلى زر «صحيح» يلغي نموذج الأمان.

مرجع التصديق التزام بالحفظ

تتيح المسودة ثلاثة أوضاع لـ Attestation Results. في وضع referenced، يحمل البيان digest وبيانات التنسيق، بينما تبقى البايتات في مكان آخر. يحمي ذلك السجل من تفاصيل حساسة ويقلل الحجم، لكنه يجعل قابلية الاسترجاع جزءاً من صلاحية التحقق العملية.

في وضع embedded، تسافر النتيجة مع البيان، فتقل مخاطر الفقد ويزداد الإفصاح عن القياسات والمنطقة والعتاد. وفي وضع registered، تحصل النتيجة على Statement وReceipt مستقلين، فتتحسن إمكانية التتبع مقابل كائن إضافي وخدمة إضافية يجب الحفاظ عليهما.

حتى النتيجة المتاحة تحتاج freshness. تذكر المسودة nonce أو epoch ID أو timestamp أو none. الأخير إفصاح بأن Evidence لم ترتبط بتحد ويمكن إعادة تشغيلها. وجود نتيجة موقعة لا يساوي أنها حديثة، وكونها حديثة لا يساوي أن تقييمها favourable.

202 هو بداية دين الدليل

تسمح SCRAPI الحالية بالتسجيل غير المتزامن. يمكن للخدمة قبول Signed Statement وإرجاع HTTP 202 مع entry identifier، ثم توفير Receipt لاحقاً عبر مورد الإدخال.

المعرف وسيلة للمتابعة، لا إثبات inclusion. على Issuer أن يقرر صراحة: ينتظر Receipt قبل الإفراج عن الأصل، أو يتقدم ويسجل الاستعادة على أنها unwitnessed حتى يُحل الإيصال. لا يجوز عرض 202 كأنه Receipt.

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

entry identifier محفوظ بلا Receipt يظل وعداً، لا برهاناً.

قياس البايتات الناتجة

يجب حساب recovered-digest من plaintext الموجود في نهاية الحدث. لا يجوز نسخه من metadata المتوقعة. القيمة المتوقعة طرف في المقارنة وليست قياساً لما أنتجته العملية.

وتحافظ قياسات البيئة على الخوارزمية والطول الأصليين. تشير المسودة إلى كود مجاور يقتطع قياسات SHA-384 بطول 48 octets في AWS Nitro وAMD SEV-SNP إلى 32 octets. يبدو الحقل ممتلئاً، لكنه لم يعد يساوي القيمة الكاملة التي تستخدمها سياسة الأصل.

أولوية running code هنا تعني العودة إلى البايتات التي قاسها التنفيذ فعلاً، لا ملء السجل بالشكل الذي توقعه التصميم.

التشغيل لا يثبت الوفاء

حقل equivalence اختياري، وغيابه يعني none. قيمة byte-identical تحتاج تطابق digest الناتج مع digest plaintext عند الختم، وأن يتحقق Issuer من المساواة. قيمة operational تعني نجاح اختبار محدد مثل التحميل أو البدء أو health probe، مع مرجع لتعريف الاختبار ونتيجته.

تصف المسودة operational بأنه ادعاء ضعيف. قد تبدأ قاعدة بيانات ناقصة. وقد يعمل نموذج بسلوك مختلف. وقد يجيب تطبيق عن probe رغم فساد قاعدة عمل أساسية.

لا توجد قيمة للتكافؤ الدلالي أو السلوكي عمداً. إعطاء اسم معياري لمفهوم غير معرف وغير منفذ سيغري الأنظمة بإصداره بعد smoke test. Receipt صالح يمكن أن يتعايش تماماً مع equivalence = none.

تسلسل Issuer ليس ترتيب السجل

يربط prev-event بيانات الاستعادة المتعاقبة للـ subject نفسه. هذه Continuity Chain تعبر عن lineage الذي يؤكده Issuer. أما السجل فيثبت الترتيب العالمي للتسجيل.

الفجوة بينهما ذات معنى: ربما لم يعرف Issuer حدثاً وسيطاً، أو اختار عدم الاعتراف به. على Verifier إظهارها لا إصلاحها. prev-entry-id وleaf index يساعدان في العثور على السابق؛ digest البيان السابق هو الرابط المشفر.

وعندما تمتد السلسلة عبر أكثر من Transparency Service، لا تتكون منها ساعة عالمية. لكل خدمة ترتيبها. وعلى المدى الطويل، تحتاج inclusion Receipts إلى consistency Receipts تربط الجذور الجديدة بالقديمة؛ العضوية في جذر منفرد لا تثبت أن السجل القديم امتد ولم يُستبدل.

الخصوصية تحدد ما يبقى قابلاً للفحص

payload المرفق يسمح للخدمة بتطبيق سياسة على claims، لكنه قد يكشف subject ثابتاً وتوقيت الاستعادة والمنطقة وعلاقة العميل بالمزود ومعرفات العتاد. payload المنفصل يقلل هذا الكشف، لكنه يمنع الخدمة من فحص claims غير الموجودة لديها ويُلزم Relying Party بقناة جانبية.

يمكن اشتقاق subject مستعار بواسطة HMAC. بذلك تقل correlation العامة، لكن سلسلتي custodian مختلفين لا تنضمان، ويصبح سر Issuer مفتاحاً طويل العمر، ويقسم تدويره السلسلة. لا يوجد اختيار خصوصية بلا أثر على التحقق اللاحق.

الكود المرجعي لا ينفذ الوثيقة

تسجل المسودة صراحة أن التنفيذ المرجعي المجاور لا ينفذ هذا التنسيق. لا يصدر COSE Receipts وفق RFC 9942، ويستخدم هياكل ربط أخرى، ولا يكمل التحقق من التصديق، ولا يربط الأدلة بـ nonce. مكون إعادة البناء Markov chain حتمية من الرتبة الثالثة على مستوى البايتات، وليس تحققاً من المعنى.

هذه حدود صادقة، لا دليل فشل إنتاجي. المقترح والكود والنشر ثلاث حالات منفصلة، ولا توجد في المصادر نتيجة تشغيل أو توافق تشغيلي.

المصادر والحدود

تصف هذه المصادر مقترحاً قيد العمل وبنى منشورة وحدود كود مجاور كما يوردها المؤلف. لا تثبت نشراً إنتاجياً أو حادثاً أو هجوماً أو استعادة فعلية أو تبنياً أو توافقاً أو وفاءً دلالياً. ملف الإفراج أدناه تحليل تشغيلي من Daniel Kade، وليس متطلباً معيارياً قائماً في revision 01.