الخلاصة

  • نُشرت المراجعة 01 من draft-wei-aic-jwt في 8 سبتمبر 2026، وهي مسودة إنترنت فردية نشطة. ليست عملاً تبنته IETF ولا معياراً معتمداً ولا دليلاً على النشر التشغيلي؛ وExperimental مجرد الحالة التي يقترحها المؤلف.
  • يضع الملف الكامل JWT للتفويض DelegationAuthorization بتوقيع الأصيل داخل AIC-JWT بتوقيع الجهة المصدرة. يحمي التوقيع الداخلي التفويض وagent_id، بينما يغطي الخارجي نص DA كما هو وبيان cnf.
  • تنص المراجعة 01 على أن DA الحالي يربط التفويض بهوية الوكيل. أما ربط مفتاح الوكيل داخل DA نفسه فمؤجل إلى إصدار لاحق؛ واليوم يحمل cnf ربط مفتاح إثبات الحيازة في الغلاف الخارجي.
  • ينبغي لإيصال ربط المفتاح أن يحدد القضية التي أثبتها كل موقّع، بدلاً من الاكتفاء بعبارة «التوقيعان صحيحان». هذا اقتراح حوكمة من Daniel Kade وليس متطلباً في المسودة.

رقم مراجعة جديد لا يصنع قراراً مؤسسياً

يسجل إعلان I-D المراجعة 01 عند الساعة 14:48 بالتوقيت العالمي في 8 سبتمبر. ويضعها Datatracker ضمن Individual Submissions بحالة I-D Exists، من دون مسار RFC أو Area Director مسؤول أو موعد telechat. يستطيع أي شخص تقديم Internet-Draft. وتعبّر عبارة “Intended status: Experimental” عن مقصد المؤلف، لا عن تبني IETF أو إجماعها أو موافقتها أو توصيتها بالتشغيل.

مع ذلك، تحمل المراجعة تغييراً مهماً. يقدم AIC-JWT نفسه تمثيلاً في طبقة التطبيق لنموذج AIC منفصل يستعمل X.509. يتيح JWT وJWS نقله في بيئات HTTP والويب وOAuth، لكنهما لا ينشئان معنى الصلاحيات أو سياسة التنفيذ. تبقى تلك المعاني في نموذج AIC ومخططات القدرات وسياسة النشر.

تبين المقارنة الرسمية أن التغيير واسع. ينتقل DA من الإصدار 1 إلى 2 لمجموعة البيانات، ويضيف حقول RFC 7523، ويُلزم تطبيقات 01 برفض الصيغة القديمة بدلاً من خفضها بصمت. والأهم أنه يفصل بين اسم الوكيل الذي جرى تفويضه وبين المفتاح الذي يستعمله عند العرض.

يثبت التوقيع الداخلي نص التفويض

في مسار PKI الموصوف، ينشئ الوكيل زوج مفاتيح ويبني طلباً بالقدرات المطلوبة ونمط التفويض والقيود وnonce. يراجع الأصيل الطلب ويوقع DA JWT ثم يعيده. بعد ذلك يقدمه الوكيل إلى CA. وفي نمط خادم تفويض OAuth يقدم الوكيل DA الموقّع كمنحة JWT bearer وفق RFC 7523.

يتضمن DA عناصر محددة: iss وsub وaud وexp وjti، إلى جانب agent_id وربط الأصيل والسبب والقدرات والنمط والقيود والعمر المطلوب والوقت وnonce. يجب أن يطابق مفتاح التحقق ربط الأصيل، وأن يساوي jti قيمة nonce. ويفصل النوع aic+da+jwt التفويض الداخلي عن الرمز الخارجي aic+jwt.

يحمل بيان da الخارجي السلسلة المضغوطة كما وصلت. ولا يجوز للمدقق إعادة بنائها أو تسلسلها قبل فحص التوقيع. لذلك لا تستطيع الجهة المصدرة تغيير قدرة أو جمهور أو نمط أو agent_id من دون إسقاط توقيع الأصيل. وفي الاتجاه الآخر، لا يكفي مفتاح الأصيل لصنع AIC-JWT خارجي صالح، لأن الجهة المصدرة توقعه.

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

يحمل cnf قرار ربط المفتاح في الطبقة الخارجية

يحدد بيان cnf الإلزامي مفتاح إثبات الحيازة للوكيل. يعرّف RFC 7800 هذه الدلالة، وتوصي المسودة ببصمة JWK من نوع jkt. عند استخدام DPoP يجب أن تطابق البصمة مفتاح الدليل، ويمكن في mTLS مقارنتها أيضاً بمفتاح شهادة العميل.

تكرر المراجعة الحد في مساري PKI وOAuth. ربط مفتاح الوكيل داخل DA محجوز لمراجعة مستقبلية لمجموعة البيانات. في الإصدار الحالي يُربط المفتاح المعروض عبر cnf وقت الاستهلاك. وبما أن cnf داخل الحمولة الخارجية، فإن توقيع الجهة المصدرة هو الذي يغطيه مع DA غير المعدل.

لا يعني ذلك أن الجهة المصدرة حرة في اختيار أي مفتاح. يبدأ المسار بتوليد الوكيل للمفتاح ومراجعة الأصيل للطلب. ويجب على CA أو AS التحقق من توقيع DA وربط مفتاح الأصيل والجمهور والصلاحية وفرادة nonce والقيود. ولا يجوز أن يتجاوز عمر الرمز الخارجي عمر المنحة الموقعة.

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

كما أن وجود cnf لا يثبت تنفيذ فحص الحيازة. تقول المسودة إن AIC-JWT ليس sender-constrained تلقائياً. إذا لم يفرض المدقق DPoP أو ما يكافئه، فقد يعمل الرمز المسروق كـ bearer credential حتى انتهاء مدته. يحدد cnf المفتاح المتوقع؛ أما قرار التحقق فيثبت أن العارض امتلكه فعلاً.

إيصال محدود يكفي لإبقاء المسؤولية

أقترح إيصالاً يتضمن hash وإصدار DA الدقيقين، ومعرف مفتاح الأصيل، وagent_id، والجهة المصدرة، وhash الرمز الخارجي، وطريقة cnf وبصمة المفتاح، وسياسة الإصدار، ونتيجة استهلاك nonce، وحد الصلاحية الفعلي، وطريقة إثبات الحيازة وقرار المدقق. وإذا أكد الأصيل المفتاح صراحة، فيسجل ذلك كبند مستقل.

يجب أيضاً فصل ساعتي منع الإعادة. يُستهلك nonce عند أول إصدار ولا يجوز أن ينتج رمزاً خارجياً ثانياً. لكن الرمز الصادر قد يعرض أكثر من مرة أثناء صلاحيته. حماية كل طلب تخص jti في دليل DPoP أو آلية مماثلة. عبارة «استُهلك nonce» لا تثبت أن كل عرض فريد.

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

يفيد Policy Mirror لدى Heng Lu في توزيع الاختيار والنتيجة: يختار الأصيل الهوية والقدرات، وتقبل الجهة المصدرة DA وتوقع ربط المفتاح الحالي، ويقرر المدقق إن كان إثبات الحيازة والسياسة المحلية ناجحين، ويتحمل صاحب المورد أثر الفعل. يؤدي اختزال ذلك في علامة خضراء واحدة إلى محو الحوكمة التي صنعت الثقة.

المصادر