الخلاصة

  • يعرّف draft-ietf-oauth-transaction-tokens-11 رمز JWT موقّعاً قصير العمر لنقل الهوية وسياق المعاملة عبر Call Chain داخل Trust Domain الذي يحدده aud. وهو Internet-Draft نشط على Standards Track في حالة WG Consensus: Waiting for Write-Up، وليس RFC ولا موافقة نهائية من IETF.
  • يجب على المستقبِل التحقق من توقيعة JWS والجمهور وانتهاء الصلاحية. تثبت هذه الفحوص سلامة الوعاء وحدوده، لكنها لا تكشف وحدها إن كانت كل قيمة في rctx أو tctx مدخلة من الطالب أو مرصودة أو مشتقة أو مثبتة استقلالاً.
  • يقترح Daniel Kade غلاف منشأ لكل ادعاء استُخدم في القرار: المصدر، والفحص المنفذ فعلاً، والراصد والوقت، والتحويل ونسخة السياسة، والحداثة، والاستعمال المسموح، والتعارضات والنتيجة. يمكن حفظ hash أو مرجع بدلاً من الرمز الكامل والبيانات الشخصية غير اللازمة. هذا ليس متطلباً من IETF.

وجد فريق التدقيق سبب السماح بعملية حساسة مكتوباً في سطر واحد: trusted_customer = true. كان Transaction Token صالح التوقيع، والجمهور صحيحاً، ولم تنته صلاحيته. لكن السجل لم يوضح هل جاءت الصفة من وثيقة هوية محققة، أم من قاعدة داخلية، أم من JSON غير موقّع أرسله workload الطالب.

لم تُزوّر التوقيعة. الذي اختفى هو الطريق الذي جعل العبارة جديرة بالثقة.

تجيب JWS عن سؤال محدد: أي مفتاح وقّع هذه البايتات، وهل تغيرت بعد ذلك؟ وتحدد Transaction Token Service، أو TTS، مجموعة الادعاءات التي تضعها في الرمز. أما السؤال المتعلق بكل قيمة ـ من شاهدها، وما الفحص الذي أُجري عليها، ومتى، ولأي استعمال تصلح ـ فلا تجيب عنه سلامة الوعاء بمفردها.

وضع النسخة الحادية عشرة جزء من الدقة

تعرض صفحة Datatracker النسخة 11 المؤرخة في 30 يوليو 2026 بوصفها Internet-Draft نشطاً لدى OAuth Working Group ومقصوداً لمسار Standards Track. عند نهاية البحث كانت حالة المجموعة WG Consensus: Waiting for Write-Up وحالة IESG هي I-D Exists. لم يكن هناك Area Director مسؤول أو موعد telechat. هذه مرحلة متقدمة، لكنها ليست RFC أو موافقة IETF مكتملة.

يبين سجل الوثيقة والفرق الرسمي بين 10 و11 أن التغيير يصحح خطأ كتابياً في تاريخ الوثيقة. نموذج الضمان الذي يناقشه هذا المقال كان موجوداً في النسخة 10. أما إعلان I-D فيثبت نشر النسخة الجديدة، لا انتهاء مسار المعايير.

المشكلة الهندسية التي تعالجها الوثيقة حقيقية. تدخل معاملة من واجهة، ثم تمر بعدة workloads. وتحتاج كل خدمة إلى قدر من الهوية والغرض ونطاق الصلاحية وتفاصيل العملية من دون أن تعيد تفسير الاعتماد الخارجي الأصلي أو تتداوله في كل خطوة. لذلك يحمل Transaction Token، وهو JWT موقّع قصير الأجل، سياقاً مشتركاً عبر Call Chain داخل Trust Domain المسمى في aud.

لكل Trust Domain يستخدم هذه الآلية TTS منطقي واحد بالضبط، وإن أمكن تشغيل عدة instances. تتحقق الخدمة من هوية workload الطالب ومن سلطته في طلب الرمز، ثم تختار السياق وتوقّعه. يحدد JWT بنية الادعاءات، ويحدد JWS التمثيل الموقّع، ويتولى OAuth Working Group تطوير المقترح.

التحقق من الاستلام لا يحسم التفويض المحلي

يلزم workload المستقبِل أن يتحقق من توقيعة JWS، وأن يتأكد من أن aud يحدد Trust Domain الخاص به، وأن يرفض الرمز المنتهي. إذا نجحت الفحوص الثلاثة، أمكن القول إن النطاق الصحيح تلقى خلال المهلة البايتات التي وقعتها TTS ولم تتغير.

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

وتمنع الوثيقة خطأين آخرين. Transaction Token ليس اعتماد مصادقة، ولا يجوز استعماله OAuth access token. يمثل access token في OAuth 2.0 منحة سلطة، بينما يمثل Transaction Token سياق معاملة. التشابه في الترميز لا يحوّل الوصف إلى إذن.

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

المجموعة موحدة، لكن أصول عناصرها متعددة

ادعاء scope إلزامي وتحدده TTS. ولا يجوز للخدمة توسيع scope الذي مثله subject token الأصلي. إذا لم تفهم scope المدخل، فعليها رفض الطلب لا اعتبار المجهول غير محدود. هذه قاعدة صريحة تمنع توسيع السلطة.

يظهر اختلاف المنشأ بوضوح في rctx الموصى به، فهو يحمل سياق الطلب أو البيئة. عندما يقدم الطالب هذا السياق، ينبغي لـTTS تقييمه. لكن القيم النهائية قد تطابق المدخل حرفياً، أو تشتق منه، أو تكون ادعاءات مستقلة من TTS. والخدمة صاحبة السلطة على مجموعة الادعاءات المتاحة؛ لا يعني ذلك أنها رصدت كل عنصر أو حققته بالطريقة نفسها.

أما tctx الموصى به أيضاً فيحمل تفاصيل المعاملة المقصود أن تبقى ثابتة عبر Call Chain. ويمكن أن تكون نسخة من تفاصيل الطلب أو مشتقة منها أو إضافات من TTS. الثبات بعد الإصدار يثبت عدم تغيير القيمة لاحقاً، ولا يثبت من أنشأها قبل التوقيع.

لنفترض أن الرمز يحمل request_ip الذي رصدته بوابة موثقة، وinvoice_total المنسوخ من كائن غير موقّع، وrisk_grade الذي حسبته TTS وفق السياسة 43 اعتماداً على credential متحقق وإشارة آنية. تشمل التوقيعة القيم كلها. لكن قوة الأول تتوقف على ثقة البوابة، والثاني على سلطة مقدم المدخل، والثالث على بيانات الحساب ونسخة السياسة.

ليس الاستنتاج أن rctx أو tctx غير موثوقين بطبيعتهما. قد يكون لبعض القيم ضمان قوي جداً. الاستنتاج أن الضمان خاص بالمصدر والفحص والوقت والتحويل والاستعمال. ويمكن لرمز واحد أن يجمع ادعاء معلناً وواقعة مرصودة ونتيجة مشتقة، بشرط ألا يسميها المستهلك كلها «مثبتة استقلالاً».

تعدد subject tokens يعني تعدد معنى «التحقق»

يمكن أن يكون subject token رمز OAuth أو SAML، أو JWT ذاتي التوقيع، أو كائن JSON غير موقّع، أو صيغة أخرى تفهمها TTS. ويلزمها التحقق منه، ومن توقيعته إن كان موقّعاً. ولذلك تتغير عملية التحقق بحسب النوع: جهة الإصدار، والمفتاح، والخوارزمية، والجمهور، والزمن، وبنية البيانات، وعقد قناة النقل.

توضح أفضل الممارسات الحالية لـJWT لماذا لا يجوز قبول الخوارزمية والمفتاح باستدلال غير آمن من الرمز نفسه. ويقدم OAuth Token Exchange إطاراً ذا صلة لتبادل الرموز، في حين تركز هذه المسودة على السياق الداخلي للمعاملة. قد يكون JSON غير الموقّع مدخلاً مشروعاً ضمن قناة محكومة، لكنه لا يكتسب بذلك أصل credential موقّع.

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

exp لا يصف حداثة كل واقعة

المتوقع أن تعيش Transaction Tokens دقائق أو أقل، وبقدر مدة الاستدعاء. ومع ذلك قد يتجاوز الرمز انتهاء subject token المقدم، إذا سمحت سياسة TTS وبعد تقييم المخاطر. قد يكون ذلك مناسباً لإكمال سلسلة قصيرة بدأت بالفعل. لكنه يعني أن exp في الرمز الجديد لا يشهد بأن كل معلومة سابقة جرى تحديثها.

وقد يبطل access token قبل موعد انتهائه. تستطيع TTS، بحسب الخطر، فحص حالة الإبطال الحالية باستخدام token introspection أو آلية مشابهة. ولا تفرض المسودة استعلاماً حياً في كل حالة. لذا فعبارتا «لم تنته المهلة» و«فُحص الإبطال الساعة 11:08 ولم يوجد» دليلان مختلفان.

لا يجوز لرمز بديل أن يوسع الأفعال المسموحة أو يغير txn أو sub أو aud. ويمكنه تقليل scope أو إضافة ادعاءات أو تمديد العمر وفق السياسة. ويجب أن يحتفظ بـCall Chain للـworkloads الطالبة، بينما تبقى وسيلة الحفظ خارج النطاق. إذا لم يُنسب الادعاء المضاف إلى خطوة الاستبدال التي أدخلته، ضغط الرمز النهائي تاريخاً متعدد المراحل في لقطة واحدة.

كما أن الحد الذي يرسمه aud حقيقي. لا يصلح Transaction Token إلا داخل Trust Domain الخاص به. أما العبور إلى نطاق آخر فتتناوله أعمال OAuth المنفصلة لتسلسل الهوية والتفويض. القدرة التقنية على فحص توقيعة نطاق آخر لا تستورد معانيه وسياساته المحلية.

ملاحظة مراجع واحد ليست إجماعاً

في رسالة WGLC بتاريخ 8 أغسطس 2026، دعم مراجع تقدم الوثيقة وصرح بأنه لا يقدم اعتراضاً مانعاً. وطلب وضوحاً أكبر في تدقيق سلاسل الاستبدال، وحذر من أن المنفذين قد يخلطون بين معلومة يحملها رمز موقّع ومعلومة أثبتها المصدر استقلالاً.

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

غلاف منشأ قريب من القرار لا نسخة من السر

اقتراح Daniel Kade التحريري هو غلاف منشأ لكل قيمة أثرت فعلاً في القرار. يسجل فئة المصدر ومعرفاً غير سري، والتحقق المنفذ فعلاً، والراصد والوقت، والتحويل ونسخة الكود أو السياسة، وجهة الإصدار ومرجع المفتاح وحد Trust Domain عند الحاجة، وفحص الحداثة أو الإبطال، والاستعمالات المسموحة، والحساسية وقاعدة التسجيل، والتعارضات، والقرار النهائي، والانتهاء والإغلاق.

يمكن أن يعيش الغلاف خارج Transaction Token، كوصل إصدار أو قرار. ويمكنه الاحتفاظ بـhash للرمز أو مرجع إلى دليل منقح. تحظر المسودة تسجيل الرموز الكاملة حرفياً بسبب خطر إعادة التشغيل والبيانات الحساسة. ويسمح hash بالربط مع سجل إصدار TTS، كما يمكن تسجيل JWS payload بلا توقيعة في ظروف مناسبة؛ غير أن payload قد يضم معلومات شخصية. وقد يعد عنوان IP أو سياق البيئة بيانات شخصية بحسب الولاية. لا يقدم المقال حكماً قانونياً.

الغاية هي إعادة بناء سبب القرار مع تقليل البيانات، لا إنشاء مخزن ثان من bearer tokens قابلة للاستعمال ومعلومات شخصية خام. يُحفظ نسب الواقعة، ولا يُنسخ السر.

المصادر