الخلاصة

  • تنص المراجعة 07 على ألا يحمل JWT أكثر من جمهور واحد، إلا إذا تعذر الحصول على بيانات اعتماد متعددة أو تعذر على حمل العمل التأثير في الجمهور؛ أما المراجعة 06 فاستخدمت صيغة SHOULD فقط.
  • الخطر هو انتحال الهوية بين الجهات المستقبلة: كل جهة تتلقى رمز الحامل نفسه تستطيع تقديمه إلى جهة أخرى تقبله.
  • ينبغي أن يوثق إيصال استثناء القدرة سبب التعذر، وخريطة المستقبلين، وعمر الرمز ونطاق وصوله، والتحقق عند كل مستقبل، والضوابط التعويضية، وموعد المراجعة، وشرط إنهاء الاستثناء.

لنفترض أن Pod يقدم رمز service account مُسقَطاً إلى خادم Kubernetes API، ثم يعيد استخدام الرمز نفسه للاتحاد مع مزود هوية خارجي. الجهتان مشروعـتان، لكنهما تحتفظان الآن بالـ bearer token نفسه. إذا سمح aud بالاستخدامين، يستطيع مزود الهوية تقديم الرمز إلى خادم الواجهة والظهور بصفة حمل العمل.

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

هذه هي النقطة التشغيلية في draft-ietf-wimse-workload-identity-practices-07، المنشور في 22 سبتمبر 2026. ما زال النص Internet-Draft نشطاً مقصوداً به تصنيف Informational. ويعرض Datatracker الحالة AD Evaluation::AD Followup مع Charles Eckel بوصفه صاحب الإجراء. هذه حالة مراجعة، وليست موافقة أو RFC أو دليلاً على نشر فعلي أو عدم امتثال منصة بعينها.

من SHOULD إلى حد يحتاج الاستثناء منه إلى تفسير

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

تجعل المراجعة 07 ذلك قاعدة. بيانات الاعتماد MUST تكون أضيق ما يمكن. البيان المخصص للوصول إلى مورد في المنصة MUST يقتصر على ذلك المورد. وبيان الاتحاد MUST يجعل مزود الهوية جمهوره الوحيد. وخارج استثناء القدرة، يجب ألا يحمل JWT أكثر من جمهور واحد.

ليس الفرق شكلياً. تسمح SHOULD بمسار بديل بعد الموازنة؛ أما MUST فتجعل الفصل هو الوضع الافتراضي، وتُلزم الاستثناء ببيان سببه. وتضيف المراجعة الآلية الأمنية صراحة: أي relying party واردة في aud نفسه يمكنها تقديم الرمز إلى جهة أخرى مدرجة فيه والحصول على وصول غير مقصود.

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

نموذج واحد وراء Kubernetes وSPIFFE والسحابة

يستطيع Kubernetes إصدار عدة projected tokens لكل منها جمهور وعمر خاصان. تفصل المراجعة 07 بين خادم API، ومورد داخلي، ومزود هوية خارجي، وتلزم استخدام رموز وجماهير مختلفة.

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

وفي مثال SPIFFE يجب أن يختلف JWT-SVID المستخدم لمورد داخلي عن المستخدم للاتحاد الخارجي. وفي نمط مزود السحابة تستبدل المراجعة 07 صيغة MUST/MUST NOT بصيغة SHOULD/SHOULD NOT الواردة في المراجعة 06 عند فصل الوصول الداخلي عن STS خارجي. التقنية تتغير، لكن السؤال الثابت هو: من يتلقى بيان الاعتماد نفسه؟

الاستثناء يصف نقصاً في القدرة، لا تصميماً مكافئاً

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

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

ينتقل العبء من الفصل التشفيري إلى الزمن، والوصول إلى المكونات، ومسارات الشبكة، ودقة التحقق، والكشف. هذه ضوابط تعويضية وليست برهاناً على التكافؤ. وتتبع المراجعة المنطق نفسه حين لا يتوفر proof of possession: تصبح الأعمار الأقصر والجمهور الأضيق وضوابط الشبكة الإضافية إلزامية. تقصير العمر لا يربط bearer token بحامله المشروع.

إيصال استثناء القدرة

ينبغي أن يحتفظ السجل بما يلي:

حقل الإيصال الدليل المحفوظ
قدرة الإصدار المنصة، المصدر، الإصدار الدقيق، وإمكان إصدار عدة بيانات
التحكم في الجمهور هل يستطيع الحمل طلب aud أو التأثير فيه، مع دليل API أو إعداد
الاستخدام المقصود API للمنصة، مورد داخلي، اتحاد، أو مورد خارجي
هوية البيان بصمة غير سرية أحادية الاتجاه أو رقم جيل، وليس قيمة الرمز
خريطة المستقبلين جميع الجهات التي تقبل الرمز ومسارات إعادة التقديم بينها
العمر TTL المطلوب والمُصدر، والتجديد، والإبطال
نطاق الوصول المكونات وmounts وsidecars والوكلاء والسجلات ومسارات الخروج
التحقق المصدر والجمهور والنوع وPoP وشروط الشبكة عند كل مستقبل
سبب الاستثناء القدرة الغائبة ولماذا يتعذر الفصل
التعويض عمر أقصر، حصر الوصول، الشبكة، المراقبة والتنبيه
المراجعة المسؤول، وقت القرار، المراجعة التالية، محفز التصحيح، وشرط الخروج

يجب أن تكون البصمة غير سرية وغير قابلة للعكس. لا يبرر الإيصال نسخ bearer token إلى تذكرة تغيير. وظيفته ربط قرار المخاطر بجيل البيان والمستقبلين والضوابط التي شملها فعلاً.

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

تناولت مادة BTW السابقة A Workload Credential Is Not the Workload ثمانية أدلة من التمهيد إلى النتيجة. أما هذا التحليل فأضيق: لدى أي مستقبلين يستطيع هذا الـ bearer token بعينه أن يتحدث بصفة حمل العمل، وإلى من يستطيعون إعادة تقديمه؟

المصادر والحدود

المصادر الأساسية هي سجل المراجعة 07، وتاريخ الوثيقة، والنص الثابت للمراجعة 07، ونص المراجعة 06. والفصل بين أداة التنسيق والواقع التشغيلي يتبع مبدأ Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

تثبت هذه المصادر حالة الوثيقة واللغة المعيارية وآلية الخطر. ولا تثبت حادثة واقعية، أو مسحاً شاملاً للتطبيقات، أو مخالفة مشغل مسمى. الإيصال اقتراح تحريري من Daniel Kade وليس مطلباً في مسودة WIMSE.