الخلاصة

  • تعني verified=true في RFC 9796 أن الجهة التي أدرجت حقل Call-Info بعينه تحققت من المعلومة التي يمثلها؛ وما زال على الجهاز المستقبل أن يملك علاقة ثقة موثقة مع تلك الجهة.
  • الإفادة تخص الحقل نفسه، ولا تتحول إلى ضمان لكل بيانات المتصل أو سبب المكالمة أو شرعية الحديث أو النتيجة. وغيابها لا يثبت الاحتيال.
  • يثبت تطابق integrity أن البايتات المسترجعة توافق الملخص المعلن. أما المصدر والحداثة والتوافر والعرض وانتباه الإنسان والشرعية فلها إيصالات مستقلة.

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

تعرّف الوثيقة استخدام بيانات الاتصال الغنية في ترويسة SIP المسماة Call-Info، وتضيف call-reason وverified وintegrity والغرض jcard. عندما تكون القيمة verified=true، فالقول المحدد هو أن الطرف الذي وضع ذلك الحقل أجرى تحققاً ناجحاً من المعلومة الممثلة فيه. اعتماد المستلم عليها يتوقف على علاقته الموثوقة بالطرف الذي استلم منه الطلب.

إذن ليست «المكالمة» كلها هي موضوع الإثبات. الموضوع حقل محدد، وصاحب الإفادة طرف محدد، ومسار الثقة صلة محددة.

يتحول الدليل عند الحد الفاصل بين الشبكة والجهاز

يحمي RFC 9795 مطالبات Rich Call Data وملخصات الموارد داخل PASSporT. يعرّف RFC 8225 بنية PASSporT ضمن عائلة الرموز التي يصفها RFC 7519، بينما يضع RFC 8224 هوية STIR في سياق SIP.

قد يستطيع مزود الإنهاء فحص التوقيع ومسار الشهادة والمطالبات، بينما لا يستطيع هاتف المشترك إجراء الفحص نفسه. يسمح RFC 9796 للمزود بترجمة النتائج المقبولة إلى Call-Info وتسليمها إلى جهاز موثق عبر واجهة مستخدم–شبكة موثوقة.

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

ينبغي أن تظل المراحل منفصلة: تقديم بيانات مرشحة؛ وصول PASSporT؛ صلاحية التوقيع والشهادة؛ مطابقة المطالبات وملخصات الموارد؛ قبول السياسة المحلية؛ تحويل جهة معلومة للنتيجة؛ إنشاء الحقل؛ توثيق النظير على UNI؛ جلب المورد؛ تطابق الهاش؛ قرار العرض؛ رؤية المستخدم؛ فعله؛ إثبات لاحق للمتصل والغرض؛ ثم النتيجة الفعلية.

وجود verified لا يقفز فوق هذه السلسلة. وغيابه يعني أن المعلومة المقابلة لم تصل مع إفادة تحقق وفق إجراءات RFC 9795، لا أن المحتال صار مثبتاً.

بطاقة المتصل مجموعة ادعاءات لا ادعاء واحد

يحدد RFC 3261 SIP وCall-Info. اسم العرض العادي في From ليس حقيقة هوية لمجرد ظهوره، وقد يُتجاهل أو يُستبدل في الطريق. يمنح RFC 9796 الشبكة طريقة أدق لبيان ما الذي تحقق منه ومن قام بذلك.

تأتي jCard من RFC 7095، وتستند صياغتها إلى JSON المحدد في RFC 8259. يقيّد ملف RCD البطاقة بكائن كيان واحد، ويطلب الاتساق بين الاسم والصورة والشعار وFrom وP-Asserted-Identity والأيقونات عندما تتداخل. الحاجة إلى الاتساق تكشف أن البطاقة تركيب من عناصر متعددة وليست حقيقة ذرية.

يمكن حمل jCard داخل URI من نوع data:، أو في جزء MIME يشير إليه cid: وفق RFC 2392، أو عبر مصدر يمكن التحقق من سلامته مثل HTTPS المرتبط بنطاق تم التحقق منه. لكل خيار جهة حراسة ونقطة فشل مختلفتان.

ويمكن استخدام data: فارغاً مع purpose=jcard لإفادة موجزة بأن اسم العرض تحقق منه المُدرِج. قلة البايتات لا تلغي صاحب القول. بل تجعل الاحتفاظ به خارج الحقل أكثر أهمية.

الهاش يحمي النسخة ولا يمنحها سيرة ذاتية

يربط integrity خوارزمية وملخصاً بالمورد المشار إليه عبر URI. يجب دعم SHA-256 وSHA-384 وSHA-512. إذا تطابقت النتيجة، ثبت أن البايتات المسترجعة هي البايتات المسماة في الإفادة.

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

كذلك فإن call-reason اختياري وقصير، وقد يُقتطع، ولا يوجد ضمان بأن يظهر. وطريقة وضع المتصل له خارج نطاق المواصفة. عبارة «تحديث الحساب» قد تساعد على اتخاذ قرار، لكنها ليست دليلاً على وجود تحديث آمن.

يوضح RFC 7852 الفكرة من زاوية أخرى في فضاء أولوية موارد SIP: للعلامة البروتوكولية معنى محدود داخل نظام تفويض، ولا تحل محل ذلك النظام. الاسم الرسمي للحقل لا يوسّع قدرته الإثباتية.

تعديل البطاقة بعد التحقق يغير موضوع التحقق

يطالب RFC 9796 بأن تقدم Call-Info نسخة واحدة متسقة من RCD. لا ينبغي للجهات اللاحقة تعديلها أو إضافة حقول متضاربة. ومن دون STIR أو حماية أخرى، لا يمكن افتراض كشف التعديلات عبر شبكات مترابطة غير موثوقة.

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

تثبت المواد العامة حالة المواصفة فحسب. تتيح نسخة النص ونسخة XML فحص اللغة المعيارية؛ وتعرض صفحة المعلومات وسجل التصحيحات وتاريخ IETF مسار الوثيقة؛ ويسجل جدول IANA لمعاملات SIP الأسماء. لا يثبت أي منها تطبيق شركة أو بوابة أو هاتف معين.

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

قيمة RFC 9796 أنه يتيح لجهاز بسيط الاستفادة من تحقق معقد. أما شرط المساءلة فهو ألا تختفي الجهة التي حملت الحكم إلى الجهاز.

المصادر