Summary

  • تضع المراجعة 01 بيانات اعتماد JWT موقعة من المُصدر داخل Authorization: DPoP وتعيد استخدام إثبات الطلب المحدد في RFC 9449.
  • لا تحدد سلامة البايتات والإثبات ما إذا كانت القيمة رمز وصول أم Credential؛ على الخادم أن يفرّق بينهما عبر iss موثوق وtyp مقبول.
  • إثبات امتلاك المفتاح لهذا الطلب لا ينشئ aud مفقوداً، ولا يثبت حداثة الحالة أو ملاءمة الإفصاح أو الإذن المحلي أو نتيجة الخدمة.

أُعيد استخدام الممر لا الحكم

يرسل Holder الـCredential كاملاً في مكان الرمز، ثم يوقّع DPoP proof يتضمن htu وhtm وiat وjti وnonce عند طلبه وath. ويبقى ath تجزئة SHA-256 لبايتات US-ASCII الخاصة بالقيمة كما استلمها الخادم. كما تُقارن مفتاحية الإثبات مع cnf.jkt أو بصمة cnf.jwk.

هذه الخطوات تثبت تماسك العرض وامتلاك المفتاح، لكنها لا تختار نموذج السلطة. يفرض ملف RFC 9068 لرمز JWT جمهوراً وat+jwt. أما الـCredential في المشروع فيحتاج إلى typ يحدده النشر، ولا يجوز أن يكون at+jwt أو نوع ID Token. إذا قبل الخادم الشكلين، فعليه فتح مسارين منفصلين بالاستناد إلى iss وtyp. وإلا فقد يطبق سياسة رمز قصير العمر على هوية قابلة لإعادة الاستخدام، أو العكس.

عنوان الطلب ليس جمهور المُصدر

يربط htu وhtm الإثبات بطريقة HTTP وURI محددين. هذه رابطة امتلاك على مستوى الطلب. أما aud، إن وُجد، فيحدده Issuer عند الإصدار ليقيد مجموعة Verifiers المسموح لها بالقبول. اختيار Holder لخادم معين لا يمنحه حق إنشاء الجمهور.

يسمح المشروع بغياب aud. عندها يمكن تقديم الـCredential إلى كل Resource Server يثق بالمُصدر نفسه. قد يشترك نظام الرواتب وأداة التطوير في موفر هوية واحد من دون أن يشتركا في تفسير claims أو الصلاحيات. لذلك يجب أن تأتي سياسة التفويض المحلية بعد التحقق، ويحظر النص استنتاج السماح من صحة الـCredential وحدها.

الحالة تحمل زمن الإلغاء

قد تعيش بيانات الاعتماد أطول بكثير من رمز الوصول. لهذا يوصي المشروع بـstatus. إذا وُجدت claim للحالة، يجب جلبها وفحصها ورفض الحالة غير الصالحة. ويمكن للسياسة رفض Credential طويل العمر بلا وسيلة حالة.

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

العرض الكامل إفصاح كامل

لا توجد هنا selective disclosure. يرى كل Verifier الـJWT كله، ويمكن للقيمة الموقعة الثابتة ربط العروض عبر الخوادم. وقد تُكتب ترويسات Authorization في access logs أو لدى proxies. يحمي TLS النقل، لكنه لا يحذف claim زائدة ولا نسخة محفوظة.

عندما يلزم اكتشاف بيانات الاعتماد أو اختيار بعض claims أو موافقة شخص، يبقى OpenID4VP مناسباً. هذا المشروع يفترض برنامجاً يعرف الخادم والـCredential مسبقاً. وحتى SD-JWT VC لا يستخدم هنا إلا كـJWT موقع من Issuer من دون disclosures.

تساعد Minimum Initial Specification لدى Lu Heng على فصل إعادة استخدام آلية مشتركة صغيرة عن تركيز كل السلطة فيها. وتطلب Running-Code Primacy إيصالات التشغيل الفعلية: typ المقبول، وثقة Issuer، وفرع الجمهور، وعمر الحالة، وإصدار سياسة التفويض، ونتيجة المورد.

Sources and limits

لا تثبت هذه المصادر تبني OAuth WG أو إجماع IETF أو RFC أو تنفيذاً أو توافقاً أو نشر agents أو إصداراً أو إلغاءً فعلياً أو قرار تفويض أو نتيجة خدمة. يحتفظ مقال RFC 9449 السابق بموضوع sender constraint العام؛ ويقتصر هذا المقال على اختلاف نموذج السلطة خلف الصيغة ذاتها.