وُقِّعت حاوية المحادثة، لكن ماذا أثبت التوقيع حقاً؟

الخلاصة

• ما زالت المراجعة 02 من overview والمراجعة 04 من core الخاصتين بـ vCon مسودتي Internet-Draft قيد العمل. يحدد المنشئ نطاق المحادثة، ويمكن أن يغيب أي من الأقسام الأربعة الكبرى.
• يستطيع JWS إثبات سلامة الـ payload وحيازة مفتاح التوقيع ضمن سياسة الثقة. لكنه لا يثبت منفرداً أن التسجيل كامل، أو أن هوية الأطراف صحيحة، أو أن الموافقة سارية، أو أن الاستنتاج التحليلي دقيق.
• تحفظ سلسلة amended حالات متعاقبة موقعة، ولا تختار تلقائياً «الرواية الصحيحة». يحتاج القرار إلى سجل أدلة يربط كل ادعاء بمصدره ونطاقه وغرضه والجهة المخولة به.

تبدو الحزمة في غرفة المراجعة مكتملة. ينجح التحقق من JWS، وتُقبل سلسلة الشهادات، وتطابق قيمة SHA-512 ملفاً صوتياً خارجياً، وتشير النسخة الأحدث إلى UUID النسخة السابقة داخل amended. تظهر على الشاشة إشارة خضراء واحدة: «تم التحقق».

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

لم يفشل التشفير. لقد أثبت بدقة أن جهات محددة التزمت ببايتات محددة. المشكلة هي تحميل هذا الإثبات إجابات عن اكتمال العالم الموصوف وعن حق الجهة في وصفه أو استخدامه.

تحمل draft-ietf-vcon-overview-02 تاريخ 30 سبتمبر 2026، وتحمل draft-ietf-vcon-vcon-core-04 تاريخ 7 سبتمبر. وهما وثيقتان من مجموعة Virtualized Conversations في IETF، وما زالتا عملاً جارياً وليستا RFC أو معياراً نهائياً. تقترحان بنية JSON تنقل بيانات المحادثة بين منصات الاتصال وخدمات التحليل ونطاقات الأمان. وكلما سهل النقل، صار فصل أنواع الضمان ضرورة أكبر.

خمس مسائل لا يصح اختزالها في كلمة «موثّق»

الأولى هي سلامة المحتوى: هل الـ payload الحالي هو نفسه الذي وُقّع؟ الثانية هوية الموقّع: إلى أي شخص أو نطاق تربط سياسة الشهادات ذلك المفتاح؟ الثالثة مصدر الالتقاط والتحويل: أي نظام شاهد كل عنصر أو أنشأه؟ الرابعة صحة المعنى: هل الأسماء والأوقات والنصوص المستخرجة والاستنتاجات صحيحة؟ الخامسة السلطة: هل كان لتلك الجهة حق الجمع والتعديل والكشف والاستخدام لهذا الغرض؟

يجيب JWS مباشرة عن الأولى ويساعد في الثانية. ويمكن لبنية vCon أن تحمل أدلة تخص الثالثة. أما الرابعة والخامسة فتحتاجان حكماً خارج الـ payload. فالادعاء الخاطئ لا يصبح صحيحاً بتوقيع صحيح، والسجل الدقيق قد يبقى غير جائز الاستخدام.

لذلك ينبغي ألا تعرض الواجهة حالة كلية اسمها «محادثة موثقة». الأدق أن تفصل: سلامة payload ناجحة، شهادة الموقّع مقبولة، تغطية الالتقاط غير مثبتة، ادعاء الهوية قيد الفحص، والغرض الحالي غير مصرح به. هذا الفصل يمنع الدليل التقني من التحول إلى سلطة ضمنية.

منشئ الحاوية يرسم حدود المحادثة

تتعامل وثيقة overview مع المحادثة بوصفها تعريفاً لا كمية طبيعية ذات حد ثابت. فقد يمثل vCon تسجيلاً واحداً، أو رحلة تبدأ برسالة ثم مكالمة وتنتهي ببريد. وفي SMS لا توجد جلسة طبيعية دائماً، فيقرر طرف ما أين يبدأ السجل وينتهي.

وتؤكد البنية هذا الاتساع: parties وdialog وattachments وanalysis كلها اختيارية. ويمكن أن يكون التسجيل بلا قائمة أطراف تعبيراً صالحاً. ويميّز core بين recording وrecording-set وtext وtransfer وincomplete، ويسمح بعنصر بديل حين تكون المعلومات قليلة. وقد لا يمثل تسجيل واحد إلا ساقاً أو قنوات محدودة من الجلسة.

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

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

تصف overview الحوار بأنه “ground truths”. المقصود أنه مادة أولية مقارنة بتحليل مشتق، لا أن المستشعر أحاط بكل الواقع. قد يكون التسجيل أصيلاً تماماً، ومع ذلك يفوّت الدقيقة التي تغير التفسير.

وجود اسم في party ليس إثباتاً آلياً للشخص

يمكن لـ Party Object أن يحمل اسماً ورقم هاتف وبريداً وSIP URI وDID وUUID وموقعاً. ويسجل validation كيفية التحقق من الهوية من دون كشف مادة التحقق. هذا فصل مفيد للخصوصية، لكنه يبقي تقييم القوة على عاتق المتلقي.

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

كذلك لا يملك UUID الدائم معنى خارج namespace الذي أصدره إلا بسياسة صريحة. يفيد في ربط موظف عبر محادثات داخل مؤسسة، ولا يتحول إلى هوية عالمية لمجرد انتقاله.

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

قد يبقى الـ hash صحيحاً بعد اختفاء الدليل

يمكن وضع الحوار والمرفق والتحليل داخل vCon أو الإشارة إليها عبر HTTPS. وتتيح content_hash مع SHA-512 مقارنة البايتات المسترجعة بما التزم به الوعاء الموقّع.

لكن core يضع التخزين الآمن والتحكم في الوصول وتبادل بيانات الاعتماد للمحتوى الخارجي خارج نطاقه. قد تعيد URL استجابة 403 أو 404، أو تحذف سياسة الاحتفاظ الملف. يبقى الـ hash دقيقاً بينما يصبح المحتوى غير قابل للفحص.

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

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

مصدر التحليل لا يساوي جودة التحليل

يستوعب Analysis Object النص المستخرج والترجمة والملخص والمشاعر والتقرير. ولا يوحّد core جميع الصيغ، فيطلب vendor ويتيح product وschema. وتعترف overview بأن التطبيقات تختلف كثيراً في الجودة والتفسير.

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

لكل نتيجة مشتقة إيصالها: فهارس ومدد hashes للمدخلات، vendor وproduct وschema، إصدار النموذج أو القواعد، الإعداد، locale، hash الناتج، معنى الثقة، مراجعة بشرية، والغرض المسموح. هذا السجل اقتراح تشغيلي من Daniel Kade، لا مطلباً معيارياً في المسودتين.

يحفظ التوقيع ما أنتجه النظام في ذلك الوقت، وهي فائدة حقيقية. لكنه لا يحول المصدر إلى دقة، ولا الدقة إلى حق في اتخاذ القرار.

للموافقة غرض وزمن ولا ترث دوام التوقيع

تعد overview الموافقة والمصدر جزءاً من سياق المحادثة. وتناقش privacy primer ومسودة lawful basis الإشعار والغرض والولاية. ولا تجعل أي منها توقيع vCon شهادة قانونية شاملة.

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

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

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

سلسلة التعديلات تحفظ الحالات ولا تعيّن الرواية الأصح

يؤدي تغيير vCon موقّع مباشرة إلى إبطال توقيعه. لذلك تُنشأ instance version جديدة، هي نسخة عميقة من السابقة مع إضافة أو تصحيح، وتشير عبر amended إلى UUID السابق وربما URL وhash. ويمكن لنطاقات أمن متعددة توقيع مراحل متعاقبة.

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

وتظهر الحدود بصورة أوضح مع redaction. يترك core طريقة إزالة النص والصوت والفيديو خارج النطاق، ويجعل ضمان الدقة مسؤولية من ينشئ النسخة ويوقعها. قد يوقّع المعالج بصدق ويترك بيانات في attachment أو analysis أو extension مجهول.

لهذا لا يجوز أن تعني «أحدث نسخة موقعة» «النسخة ذات السلطة». قد يحق لخدمة التحليل إضافة transcript ولا يحق لها تغيير هوية طرف. وقد يحق لنطاق أن يحجب بيانات عن جمهور ولا يحق له إتلاف الأصل.

قرار تجاه extension يتغير بتغير العملية

تضيف extensions حقولاً وقد تعيد تعريف المعنى أو تلغي parameters. ويجب إدراج غير المتوافق منها في critical؛ أما processor الذي لا يدعمه فعليه الرفض أو الإبلاغ بدلاً من المعالجة.

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

ينبغي تسجيل قائمة extensions وcritical وإصدار registry والبرنامج والعملية وسبب التجاهل أو الرفض. نجاح تحليل JSON لا يثبت فهم المعنى.

سجل أدلة المحادثة يربط الحاوية بالعالم

لكل قرار، يُربط UUID وhash وشكل vCon بالنطاق والفجوات والأنظمة والنطاقات المساهمة، وهوية الموقّع وحالة الشهادة وسياسة الثقة، وأدلة الأطراف، وتغطية الالتقاط، والوصول الخارجي، ومدخلات التحليل وإعداده، وسلطة الغرض، وقدرة extensions، والسابق والفروق، والقرار وصاحبه وطريق التراجع.

ويفصل السجل بين ما لوحظ وما نُقل. «تطابق SHA-512 للبايتات المسترجعة» ملاحظة. «تم التحقق من الهوية ببيانات اعتماد» ادعاء داخل payload حتى يُربط بحدث. «يجوز استخدامه للجودة حتى تاريخ معين» قرار محلي.

المسار هو: النطاق -> الاسترجاع -> فحص البايتات -> تحديد الموقّع -> تفويض ادعاءاته -> فحص extensions -> بناء النسب -> التحقق من الادعاءات -> تفويض الغرض -> تسجيل الاعتماد -> مراقبة السحب.

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