الخلاصة

  • تسأل Call for Adoption في HTTPbis ما إذا كان ينبغي أن يصبح draft-hardt-httpbis-signature-key-08 عملاً لفريق العمل؛ وحالة Datatracker تعني أن السؤال ما زال مفتوحاً ولم يصل الفريق إلى إجماع للتبني.
  • تقترح المسودة طرقاً للعثور على مفتاح تحقق أو حمله. أما قرار قبول صاحب المفتاح لتنفيذ فعل معين فيبقى قراراً محلياً له سياسة وصاحب ودليل مختلف.

تسرد الرسالة العامة خمسة حقول HTTP وثماني طرق أولية لتوزيع المفاتيح أو اكتشافها: مفتاح مضمن باسم مستعار، تفويض مربوط ببصمة JWK، URI لـ JWKS، وJWKS مباشر، وصيغ JWT، وJWT ذاتي الإصدار، وسلسلة X.509، وإحالة إلى assertion مخزنة. هذه ليست قائمة بثمانية أطراف مخولين. إنها قائمة بمسارات محتملة تصل بها الجهة المتحققة إلى مادة عامة تستخدم في التحقق.

لذلك فالسجل الذي أنشأته الدعوة محدود وواضح. طلبت HTTPbis من القائمة أن تعلن تأييدها أو اعتراضها مع الأسباب قبل 7 سبتمبر 2026. توضح صفحة حالات IETF أن Call For Adoption By WG Issued هي دعوة لا تزال جارية ولم يصل فيها الفريق إلى consensus لاعتماد النص. قرار لاحق من chairs، ووثيقة فريق، ومراجعة، وفعل IESG، ونشر RFC ستكون كلها سجلات مستقلة إن وقعت. لا تصبح مهلة الرد تاريخ اعتماد أو ضمان تشغيل.

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

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

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

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

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

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

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

المصادر