توثيق بوتات الويب في ٢٠٢٦: تم الشحن قبل أن يصبح معياراً قياسياً

إن Web Bot Auth ليس معياراً معتمداً من IETF بعد. حتى 12 أغسطس 2026، لا تمتلك مجموعة العمل الخاصة به أي وثائق معتمدة — فقط مسودات فردية — بينما تقوم Cloudflare و AWS WAF و Akamai و HUMAN و Vercel بالفعل بالتحقق من توقيعاته في بيئة التشغيل الفعلية لتحديد أي من وكلاء الذكاء الاصطناعي (AI agents) يمكنهم الوصول إلى الموقع الإلكتروني.

هذه الفجوة لها عواقب الآن. فقد غيرت المسودات تنسيق السلك الخاص بـ Signature-Agent من سلسلة نصية بسيطة إلى قاموس مهيكل في أكتوبر 2025، وتنص المراجعة المؤرخة في 6 أغسطس 2026 — والتي نقلت العمل أيضاً إلى مسار المعايير (Standards Track) — على القاعدة صراحةً: "يجب على الموقعين إرسال صيغة القاموس."¹ ومع ذلك، لا تزال قواعد التحقق المنشورة من Cloudflare تعامل صيغة القاموس هذه كسبب لفشل الطلب.²

ملخص: يتيح Web Bot Auth للعميل الآلي توقيع كل طلب HTTP باستخدام توقيعات رسائل HTTP (RFC 9421)، بحيث يمكن للموقع التحقق من هوية المتصل بدلاً من الثقة في سلسلة user-agent.³ الانتشار واسع وآلي في الغالب. لكن عملية التقييس لم تنتهِ: هناك تسع مسودات نشطة تتطابق مع اسم مجموعة العمل ولم يتم اعتماد أي منها، وقد تعهد مؤلفو المسودة الأساسية في IETF 126 بالاستمرار في تحسينها "قبل السعي للحصول على اعتماد رسمي"، ولا تزال وثائق الموردين التي تتحكم في حركة المرور الحقيقية تصف تنسيق ترويسة (header) تركته المسودات خلفها في عام 2025.⁴⁵¹

ما ستتعلمه

• ما هو Web Bot Auth فعلياً، وما الذي يساهم به RFC 9421 في ذلك
• الوضع الحقيقي لمجموعة عمل IETF اعتباراً من أغسطس 2026
• ما الذي قررته جلسة IETF 126 في فيينا، وما الذي لم تقرره صراحةً
• أي من شبكات CDN و WAFs ومشغلي الوكلاء يطبقونه بالفعل اليوم
• لماذا انقسمت ترويسة Signature-Agent في النظام البيئي إلى صيغتين غير متوافقتين
• لماذا يوجه أربعة من القائمين على النشر القراء إلى مسودات مستبدلة وطلب اجتماع
• ما الذي يرفض الميثاق حله، بما في ذلك من هو الشخص الذي ينوب عنه الوكيل
• ماذا تفعل الآن إذا كنت تدير موقعاً أو تشغل وكيلاً

ما هو Web Bot Auth فعلياً

Web Bot Auth هو وسيلة للعميل الآلي لإثبات الجهة المشغلة التي ينتمي إليها تشفيراً، في كل طلب. ينشر البوت مفتاحاً عاماً كمجموعة مفاتيح JSON Web Key Set في /.well-known/http-message-signatures-directory على نطاق يتحكم فيه، ويقوم بتوقيع الطلبات الصادرة باستخدام توقيعات رسائل HTTP — RFC 9421، وهو RFC من مسار المعايير نُشر في فبراير 2024.³²

هناك ثلاث ترويسات تحمل هذا التوقيع. ترويسة Signature-Input تحدد المكونات التي يتم توقيعها والمعاملات (keyid، و created، و expires، و nonce، و tag). وترويسة Signature تحمل البايتات. أما ترويسة Signature-Agent فتشير إلى الدليل الذي يحتوي على المفتاح.

Signature-Agent: "https://signature-agent.test"
Signature-Input: sig2=("@authority" "signature-agent")
 ;created=1735689600
 ;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519"
 ;expires=1735693200
 ;nonce="e8N7S2MFd/qrd6T2R3tdfAuuANngKI7LFtKYI/vowzk4lAZYadIX6wW25MwG7DCT9RUKAJ0qVkU0mEeLElW1qg=="
 ;tag="web-bot-auth"
Signature: sig2=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:

هذا هو المثال الموثق من Cloudflare — وهو نموذج تمت مراجعته أدناه — و keyid هو بصمة JWK بتنسيق base64url الخاصة بالمفتاح.² Ed25519 هو الخوارزمية الوحيدة التي تقبلها Cloudflare؛ بينما المسودة ليست مرتبطة بخوارزمية واحدة، حيث تحصر alg في سجل خوارزميات توقيع HTTP الخاص بـ IANA وتحمل نواقل اختبار RSASSA-PSS إلى جانب نواقل Ed25519.²¹

قوائم السماح الخاصة بـ IP تتعطل عندما يقوم المزود بإعادة هيكلة النظام؛ أما سلاسل user-agent فهي نصوص حرة يمكن لأي شخص نسخها. لكن التوقيع يمكن التحقق منه. وهذا ما ينص عليه الميثاق: "قوائم السماح بـ IP، وسلاسل User-Agent، ومفاتيح API المشتركة" لديها "قيود كبيرة فيما يتعلق بالأمان، وقابلية التوسع، وسهولة الإدارة".⁶ لا يوجد خلاف حول بيان المشكلة هذا، بل الخلاف هو حول شكل الحل.

الجدول الزمني للمعايير: تسع مسودات، لم يتم اعتماد أي منها

ابحث في IETF Datatracker عن webbotauth في 12 أغسطس 2026 وستجد تسع مسودات إنترنت (Internet-Drafts) نشطة. كل واحدة منها هي تقديم فردي — draft-meunier-*، draft-illyes-*، draft-nottingham-*، draft-rescorla-*، draft-singh-*، draft-popov-*. لا يوجد أي draft-ietf-webbotauth-anything، وتضيف قائمة مستندات مجموعة العمل نفسها مسودة فردية عاشرة لا يحمل اسمها بادئة المجموعة.⁴⁷

هذه البادئة ليست مجرد شكل: فالمسودة الفردية هي اقتراح شخص واحد؛ أما مستند draft-ietf- فهو مستند تملكه المجموعة.

تمت الموافقة على الميثاق في 23 أكتوبر 2025 مع ثلاثة معالم رئيسية: مواصفتان في مسار المعايير تُقدمان إلى IESG بحلول 30 أبريل 2026، ومواصفة تشغيلية لأفضل الممارسات الحالية بحلول 31 أغسطس 2026.⁸⁶ وعمود المستندات المرتبطة فارغ لجميع هذه المعالم الثلاثة.

لنكن منصفين بشأن ما يعنيه ذلك وما لا يعنيه. المعالم هي أهداف يديرها الرؤساء، وليست مواعيد نهائية تترتب عليها عواقب، وتجاوزها هو الأمر المعتاد في IETF وليس الاستثناء. عقدت هذه المجموعة ثلاث جلسات بصفتها مجموعة عمل معتمدة — IETF 124، وجلسة مؤقتة في أبريل 2026، و IETF 126 — بعد جلسة ما قبل الميثاق في IETF 123، وقد مر ميثاقها من IESG بستة أصوات مؤيدة وبدون اعتراضات.⁹¹⁰ مرور ما يقرب من عشرة أشهر دون دعوة للاعتماد هو أمر غير متسرع، وليس دليلاً على الفشل. ما يجعل الأمر مؤثراً ليس التقويم، بل حقيقة أن طبقة التنفيذ لم تنتظر.

ماذا حدث في IETF 126

اجتمعت المجموعة في فيينا في 22 يوليو 2026.⁵

أجرى الرؤساء استطلاعاً واحداً حول مسار تحديد الهوية والمصادقة: "هل نعتقد أن هذا هو الاتجاه العام الصحيح / نقطة البداية الصحيحة؟" النتيجة: نعم: 22، لا: 6، لا يوجد رأي: 5، من بين 75 مشاركاً.⁵ استطلاع الاتجاه ليس دعوة للاعتماد، ولكن نسبة 22-6 هي هامش مريح.

إجراء العمل هو الأكثر أهمية. "سيواصل المؤلفون تحسين المسودة لمعالجة الاكتشاف الرئيسي، ودلالات تدوير المفاتيح، والملاحظات التشفيرية المتعلقة بهياكل التوقيع قبل السعي للاعتماد الرسمي."⁵ وقد أشار Justin Richer — وهو أحد محرري RFC 9421 نفسه — إلى أن "توقيع قيمة التوقيع يمثل مخاطرة تشفيرية معروفة" وعرض المساعدة في مواءمة البناء مع أفضل الممارسات.⁵³

كان هناك أيضاً جدال حول القيم. حذر Eric Nygren و Richard Barnes و Alissa Cooper من أن النظام التطوعي "قد يصبح متطلباً فعلياً للوصول إلى محتوى الويب، مما قد يؤدي إلى ويب تمييزي أو تفتت رقمي." ورد Marwan Fayed "بأنه بدون مثل هذا المعيار، سيستمر المشغلون في حظر حركة المرور غير المعترف بها على أي حال، مما يجعل وجود مسار معياري ضرورياً للحفاظ على الوصول المفتوح."⁵

هناك مرشح لمعلم BCP في 31 أغسطس. قدم Gary Illyes عرضاً عن أفضل الممارسات للزواحف (crawlers) — draft-illyes-webbotauth-cbcp-00، وبحالة مقترحة كـ Informational.⁴ وقد "دعم Richer الاعتماد بقوة" وأشار AD Mike Bishop إلى أن معلم BCP الخاص بالميثاق يعني أن العمل "من المرجح أن يكون قريباً بما يكفي للمضي قدماً"، رغم أن الرئيس المشارك David Schinazi وصفه بأنه "خارج ميثاق WEBBOTAUTH الحالي من الناحية الفنية" ونصحت Mirja Kühlewind بإعادة صياغة الميثاق رسمياً "لتجنب مشكلات IETF Last Call."⁵ أما مسار المصادقة المجهولة الموازي لـ Eric Rescorla "سيبقى في مرحلة استكشافية."⁵¹¹ وكان الرؤساء يدرسون إمكانية وضع مرحلة انتقالية قبل IETF 127 في نوفمبر.⁵

من يطبق Web Bot Auth بالفعل

لقد تم إطلاق طبقة التنفيذ.

لاحظ التواريخ. قامت Vercel بتفعيل التحقق في 12 أغسطس 2025 — أي قبل حوالي عشرة أسابيع من تأسيس مجموعة العمل — وقامت AWS بذلك بعد أربعة أسابيع.^{14126 لقد انقلبت الإعدادات الافتراضية من الرفض إلى السماح، بكلمات AWS: "سابقاً، كانت فئة AI تحظر البوتات غير الموثقة؛ هذا السلوك تم تحسينه الآن لاحترام تحقق WBA."12 مسودة غير معتمدة هي الآن الفرق بين حظر العميل الذكي (agent) أو السماح له بالمرور.}

الانقسام بين التوقيع والوكيل، وأي جانب هو القديم

تقول وثائق Google إن الطلبات المشاركة تحمل Signature-Agent مضبوطاً على g="https://agent.bot.goog"، وتطلب من القراء "ملاحظة تسمية g=."¹⁵ بينما تقول OpenAI إن الترويسة هي "https://chatgpt.com" وتوجه جهات التحقق للتأكد من أنها "تتطابق تماماً" مع هذه القيمة، "بما في ذلك علامات الاقتباس."¹³ أما Cloudflare فتطبق السلسلة المقتبسة المجردة وتدرج ضمن إخفاقات التحقق الخاصة بها: "تستخدم الرسالة صيغة القاموس من المسودات اللاحقة، مثل sig2="https://signature-agent.test"."²

القراءة البديهية — بأن Google هي الاستثناء — خاطئة، والتواريخ تؤكد ذلك. فقد ظهرت صيغة القاموس في draft-meunier-web-bot-auth-architecture-04 في 20 أكتوبر 2025 — وهو تغيير يسجله سجل تغييرات المسودة الحالية على أنه "تغيير Signature-Agent إلى قاموس حقول مهيكلة."¹ وبعد تسعة أشهر ونصف، تنص المراجعة الحالية على القاعدة صراحةً: "Signature-Agent هو ترويسة مهيكلة من نوع قاموس... يجوز لجهة التحقق قبول صيغة [السلسلة المجردة] ومعاملتها كقاموس بعضو واحد... يجب على الموقعين إرسال صيغة القاموس." ولا تزال أمثلة السلسلة المجردة موجودة فقط في الملاحق التي تحمل عنوان "Legacy Signature-Agent, sf-string"، مع ملاحظة "تم الاحتفاظ بها للمنفذين الذين ينتقلون إلى صيغة القاموس (القسم 5.2.1). لا تقم بنسخها في عمليات النشر الجديدة."¹

لذا، فإن Google تشحن ما حددته المسودات منذ عام 2025؛ بينما تعامل قواعد Cloudflare هذه الصيغة كفشل، وتقوم OpenAI بالتوقيع باستخدام الصيغة القديمة. التداخل حرفي: طلب المثال الخاص بـ Cloudflare هو حرفياً وبكل تفاصيله المتجه الذي تضعه المسودة تحت بند "Legacy."²¹ وللدقة، هذا يقارن الوثائق المنشورة، وليس حالات الرفض الملحوظة: فقد تتعرف Cloudflare على Google-Agent من خلال دليل البوتات الموثقة الخاص بها، وعبارة MAY accept تترك لها الحرية في الاستمرار في قبول الصيغة القديمة. ولكن مشغل الموقع الذي يتبع صفحة أي مورد واحد سيقوم بالتنفيذ بناءً على جيل خاطئ من المواصفات.

قصة إعادة التشغيل (replay) تسير على النحو نفسه. يقول قسم مكافحة إعادة التشغيل في المسودة إن الوكلاء ينبغي عليهم إضافة nonce ويجب عليهم الحفاظ على تفرده خلال نافذة صلاحية التوقيع، تاركين التنفيذ للمصدر.¹ وتقول وثائق Cloudflare بوضوح: "لا يوجد حالياً تحقق من الـ nonce، كما أن Cloudflare لا تحمي من هجمات إعادة التشغيل باستخدام قاعدة بيانات للـ nonces التي تمت رؤيتها،" وتوصي بدلاً من ذلك بقيم expires قصيرة: "دقيقة واحدة غالباً ما تكون كافية."²

أربعة جهات نشر، مسودات مستبدلة وطلب اجتماع

مشكلة الاستشهادات القديمة هي مشكلة منهجية. توثيقات Cloudflare، التي تم تحديثها لآخر مرة في 1 يوليو 2026، تقول إنها تعتمد على draft-meunier-http-message-signatures-directory-03 و draft-meunier-web-bot-auth-architecture-02.² كما يشير دليل Google إلى نفس سلسلتي المسودات.¹⁵ وكلاهما الآن مصنف كـ مستبدل (Replaced) في الـ Datatracker — بواسطة draft-meunier-webbotauth-httpsig-directory و draft-meunier-webbotauth-httpsig-protocol على التوالي — وقد استوعبت مراجعة أغسطس محتوى وثيقة الدليل.⁷¹ كما تشير سجل التغييرات في Vercel إلى مسودة البنية التحتية أيضاً.¹⁴ أما AWS فتربط عبارة "IETF drafts" بـ bofreq-nottingham-web-bot-auth: وهو طلب Birds-of-a-Feather معتمد: وهو عبارة عن مقترح لعقد اجتماع.¹²

لا يوجد ملف واحد تشير إليه هذه الصفحات، وكل واحد من هذه الروابط يؤدي إلى مكان آخر غير المواصفات الحالية. وقد واجهت جهود IETF في agentproto المشكلة ذاتها — حيث أن مسودة مستشهد بها على نطاق واسع هناك قد انتهت صلاحيتها وتم أرشفتها الآن.

ما يرفض الميثاق حله

يجب على أي شخص يقوم ببناء تجارة تعتمد على الوكلاء (agentic commerce) قراءة قائمة "خارج النطاق" قبل افتراض أن Web Bot Auth تغطيهم. نصاً، من بين العناصر السبعة الخارجة عن النطاق:⁶

• "توثيق الوصول إلى المحتوى غير المخصص للاستهلاك البشري (على سبيل المثال، HTTP APIs، الواجهات من وكيل إلى وكيل)"
• "توثيق المستخدم النهائي لعميل أو وكيل مشارك"
• "تتبع أو تعيين سمعة لبوتات معينة"
• "تقنيات لتمييز البوتات غير المشاركة عن العملاء غير البوتات"

الميثاق صريح في ذلك: "سيركز هذا الجهد على توثيق الوكيل؛ أما توثيق المستخدم النهائي فهو خارج النطاق."⁶

وبناءً على ذلك، فإن التوقيع الموثق يخبر التاجر أن الطلب جاء من ChatGPT. ولكنه لا يقول شيئاً عن جلسة مَن، أو ما إذا كان هذا الشخص قد وافق، أو ما إذا كان مسموحاً له بإنفاق أي شيء. وتصل ملاحظة قدرات OpenAI إلى نفس النتيجة من جانب المنتج: عند الإطلاق، "لا يمكن لمتصفح Cloud تسجيل الدخول إلى المواقع الإلكترونية أو إكمال عمليات الدفع".¹³

تقوم Cloudflare بالتجربة عند تلك النقطة باستخدام ترويسة RFC 7239 Forwarded — Forwarded: for="openai"، واختياريًا مع إشارة استخدام المحتوى use="reference" — وتصف صفحتاها الخاصتان التجربة بشكل مختلف. تضع صفحة Web Bot Auth الأمر في إطار نقل "هوية المشغل" عبر الوسطاء؛ بينما تقول صفحة البوتات الموثقة (Verified bots)، التي تم تحديثها في نفس اليوم، إن Cloudflare "تجرب توجيه معلومات حول المستخدم النهائي".²¹⁶ كلاهما يصفها بأنها تجريبية؛ وفي كلتا الحالتين فهي إضافة من المورد، وليست وثيقة صادرة عن مجموعة عمل.⁶ تظل مسألة من هو الإنسان الذي يقف وراء العميل (agent) مشكلة مفتوحة تحاول الهوية التشفيرية للعميل و تفويض العميل على طبقة البروتوكول معالجتها من اتجاهات أخرى.

ماذا تفعل الآن

إذا كنت تدير موقعًا. استخدم نظام التحقق الخاص بمزود الخدمة بدلاً من كتابة نظامك الخاص؛ فجميع أدوات التحقق الخمس المذكورة أعلاه تقوم بذلك نيابة عنك.²¹²¹³ احتفظ بخيار الرجوع إلى IP و reverse-DNS: حيث تخبرك Google بذلك صراحةً، لأنها لا تقوم بتوقيع كل طلب.¹⁵ في AWS WAF، تأكد من أنك ضمن النطاق، لأن الميزة تغطي توزيعات CloudFront فقط.¹²

إذا كنت تشغل عميلاً (agent). انشر دليل مفاتيح وقم بالتوقيع، لأن التوجه الافتراضي يميل بالفعل نحو السماح بحركة المرور الموثقة. أرسل صيغة القاموس لـ Signature-Agent، لأن هذا ما تتطلبه المسودة الحالية — وتوقع أن تطلب بعض أدوات التحقق السلسلة النصية القديمة لفترة من الوقت.¹ حدد نوافذ expires قصيرة نظرًا لضعف حماية إعادة التشغيل (replay protection) المنشورة، وتابع draft-meunier-webbotauth-httpsig-protocol، وليس الأسماء القديمة التي تذكرها صفحات الموردين.²¹

إذا كنت تكتب لغة تعاقدية للمشتريات. لا تسمِّ Web Bot Auth "معيارًا" في العقد. إنها مجموعة من المسودات الفردية ذات الانتشار القوي، ولكن لا يوجد نص معتمد، وهناك جدال لم يُحل داخل مجموعة العمل حول ما إذا كانت الآلية ستظل تطوعية على الإطلاق.⁵

الخلاصة

النمط المعتاد هو وصول المواصفات قبل سنوات من قيام أي شخص بنشرها. لكن Web Bot Auth عكس ذلك: قامت Vercel بشحن التحقق قبل عشرة أسابيع من تأسيس مجموعة العمل، وAWS بعد أربعة أسابيع، ولم يتم اعتماد أي شيء منذ ذلك الحين. غيرت المسودات تنسيق النقل (wire format) في أكتوبر 2025 وجعلته إلزامياً "MUST" في أغسطس الماضي — بينما موقع التوثيق الذي يتبعه أصحاب المواقع فعلياً تم تحديثه لآخر مرة في 1 يوليو.

مجموعة العمل ليست هي المشكلة — فاستطلاع التوجه بنتيجة 22-6، ومسودة مرافقة مدمجة، ومرشح BCP بتشجيع من AD، كلها تشير إلى الاتجاه الصحيح. المشكلة تكمن في أن لوحات التحكم التي تقرر أي العملاء يصلون إلى الويب تتحقق من تنسيق نقل تخبر المواصفات المطورين بعدم نسخه في عمليات النشر الجديدة.