الخلاصة

  • نشر W3C مواصفة Web Authentication Level 3 كتوصية في 25 أغسطس 2026، وربطها بلقطة ثابتة لتقرير التنفيذ مؤرخة في 26 يونيو.
  • يعلن التقرير 53 اختباراً و415 اختباراً فرعياً على إصدارات محددة من Chrome وFirefox وSafari Preview وEdge، مرتبطة جميعاً بالإصدار نفسه من WPT.
  • يقول سجل الانتقال النهائي إن جزءاً من Chrome يختلف عن Edge، من دون تعيين ذلك الجزء. المطلوب مفتاح على مستوى الميزة يربط طبقة التنفيذ ودليل الاستقلال ونتيجة التشغيل واستخدامها في القرار.

التقرير يثبت أين جرى الاختبار

تحدد Web Authentication: An API for accessing Public Key Credentials — Level 3 كيفية إنشاء تطبيقات الويب لبيانات اعتماد بالمفتاح العام، مقيدة بالطرف المعتمد، وكيفية استخدامها عبر وكيل المستخدم والمصادق. والنسخة المؤرخة في 25 أغسطس توصية رسمية؛ يدعو W3C إلى نشرها على نطاق واسع، ويقول إن النص لم يتلق تغييرات جوهرية بعد لقطة Candidate Recommendation الصادرة في 26 مايو.

وفي مقدمة الوثيقة رابط لتقرير تنفيذ ثابت. يعلن التقرير أنه لقطة لحالة web-platform-tests في 26 يونيو، وينبه إلى أنه لا يخضع للتحديث وأن النتائج الجارية موجودة في الخدمة الحية. وتقول الصفحة إن مسار /webauthn/ يضم 53 اختباراً و415 اختباراً فرعياً.

يحفظ التقرير سياق التشغيل بدقة. شُغّل Chrome 151 وFirefox 154 alpha على Linux في 25 يونيو، ثم Safari 246 Preview على macOS وEdge 151 على Windows في اليوم التالي. وتشير الحالات الأربع إلى commit واحد هو d41367df1e. وبعد ذلك تعرض المصفوفة حالات PASS وFAIL وTIMEOUT وERROR وNOTRUN والنتيجة المفقودة.

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

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

السؤال ظهر في الاجتماع ثم اختُصر إلى كلمة «جزء»

يضع issue الانتقال النهائي رابط النتائج الحية واللقطة الثابتة تحت عنوان «Implementation». وبعدهما مباشرة تأتي الجملة التي تفيد بأن جزءاً من التنفيذ في Chrome مختلف عن Edge.

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

تحتفظ محاضر 18 مارس بسياق أدق. ففي موضوع «Testing» ورد أن لدى Edge بعض الاختلافات التقنية عن «Chrome العادي». ثم سأل النقاش هل يعمل Microsoft Authenticator من خلال Android أم iOS، ووصف المسارين، بالنسبة إلى امتداد محدد، بأنهما تطبيقان على طبقة WebAuthn. وسجلت المحاضر لاحقاً توافق المجموعة، بلا اعتراض، على طلب التوصية بعد حل القضايا المعلقة.

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

أما القرار نفسه فمكتمل. يسجل issue موافقة فريق W3C في 17 يوليو، وانتهاء مراجعة اللجنة الاستشارية في 18 أغسطس بتوافق ومن دون اعتراضات رسمية، ثم الإذن بالنشر في 19 أغسطس ورابط التوصية في 25 أغسطس. نقص التفصيل العام لا يحول هذه الخطوات إلى مسودة، ولا يثبت أن الأدلة الأخرى لم تكن موجودة.

إجراءات W3C لا تستخدم عدد المتصفحات معادلةً

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

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

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

سجل صغير على مستوى الميزة

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

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

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

يفرق Lu Heng في Minimum Initial Specification بين التوصية بوصفها أثراً للتنسيق وبين التنفيذ والتحقق والنشر والتبني كحقائق تشغيلية. والانضباط نفسه مطلوب في الدليل السابق للقرار: اسم المتصفح يثبت المنتج المختبَر، ولا يثبت وحده نسب التنفيذ تحته.

المصادر