الخلاصة

  • يضع ميثاق فريق Web Authentication المقترح توقيع بيانات اعتباطية ضمن نطاق العمل، على أن يتوسط WebAuthn العملية وأن تكون مفتاح التوقيع مرتبطة ببيانات الاعتماد ولكن منفصلة عن مفتاح المصادقة.
  • يذكر النص الذكاء الاصطناعي القائم على الوكلاء وبيانات الاعتماد الرقمية القابلة للتحقق، مع استمرار استبعاد الوصول منخفض المستوى إلى المفاتيح الخاصة وواجهات التشفير العامة المستقلة خارج الوظائف المحددة.
  • إدخال الموضوع في النطاق لا يعني النضج: مراجعة الميثاق ما زالت مفتوحة، ولا يملك Level 4 مسودة FPWD، وطلب sign ما زال Draft، ولا تسجل وثيقة الشرح بحثاً مع المستخدمين أو مواقف من Chrome أو Firefox أو Safari أو Edge.
  • ينبغي إنشاء سجل علني لقبول الميزة يربط سلطة الميثاق بنسخة المقترح الدقيقة، وحدود المفتاح والرسالة والموافقة، والمراجعات، والاختبارات، والتنفيذات المستقلة، وحالة Recommendation، والتبني الفعلي.

الميثاق يمنح سلطة البحث ولا يختار النتيجة

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

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

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

لكن الفعل المؤسسي الجاري أضيق من ذلك بكثير. فتح W3C المراجعة في 10 أغسطس، وتغلق التعليقات عند 23:59 بالتوقيت العالمي في 7 سبتمبر، بينما مُدد الميثاق الحالي حتى 30 أكتوبر. عند نقطة القطع لهذه المقالة، لم يُعتمد الميثاق الجديد. وحتى إذا اعتمد، فمعناه أن الفريق يستطيع تطوير هذه الفئة من الوظائف. لا يعني اختيار واجهة طلب السحب الراهنة، ولا حل مخاطرها، ولا إلزام أي متصفح بتنفيذها.

الميثاق نفسه يحافظ على المسافة. فهو يسمي Web Authentication Level 4 مخرجاً معيارياً مقترحاً، لكنه يقر بعدم نشر First Public Working Draft، ويضع الربع الأخير من 2028 موعداً متوقعاً للإنجاز. فتح باب العمل قرار حقيقي؛ أما الوصول إلى شفرة متوافقة تعمل في أجهزة المستخدمين فقرار وسلسلة أدلة أخرى.

توقيع البايتات لا يثبت أن الإنسان فهم القرار

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

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

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

هذه التزامات تصميمية ذات قيمة، لكنها لا تثبت أن الشخص فهم الحمولة.

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

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

الأدلة المنشورة ما زالت في مرحلة الحضانة

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

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

يوفر W3C Process السلم الذي يمنع اختزال المراحل. فالتغيير الكبير في النطاق يحتاج مراجعة Advisory Committee وقرار W3C. ويبدأ FPWD العمل العام في مسار المعايير وله آثار تتعلق ببراءات الاختراع. وتفحص المراجعات الأفقية الوصول وإتاحة الاستخدام والتدويل والخصوصية والأمن. وتطلب Candidate Recommendation مراجعة نهائية وخبرة تنفيذ، بينما تحتاج Recommendation إلى أدلة وقرار إضافيين. بعد ذلك كله يقرر منفذو المتصفحات وأدوات المصادقة والأطراف المعتمدة ما إذا كانوا سينشرون الوظيفة.

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

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

سجل قبول واحد للميزة يحفظ تسلسلها

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

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

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

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

المصادر

  1. دعوة W3C إلى مراجعة ميثاق Web Authentication المقترح
  2. ميثاق فريق Web Authentication المقترح
  3. ميثاق فريق Web Authentication الحالي
  4. توصية Web Authentication Level 3
  5. وثيقة شرح امتداد التوقيع الخام
  6. طلب السحب Draft لامتداد sign رقم 2078
  7. وثيقة W3C Process بتاريخ 18 أغسطس 2025
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption