تغيّر المفتاح، لكن استمرار هوية المثيل ظل رهناً بسجل محفوظ

الخلاصة

• يتيح المقترح للموثِّق الاحتفاظ بقيمة client_instance_id عبر تبديل موثَّق للمفتاح، لكن حجية هذه القيمة تأتي من سجل التسجيل لا من نص المعرّف.
• استمرارية الهوية، واستمرارية ربط المفتاح، وسلطة الموثِّق، وربط المنحة، وخريطة الرمز، وإثبات مقدّم الطلب قرارات منفصلة.
• يتطلب التشغيل القابل للمراجعة إيصال استمرارية يربط المُصدر والتسجيل والحبيبية وReceiver Scope والمفتاحين والحدث ودليل العهدة والنضارة وخريطة Consumer Scope وإثبات المقدم الحالي.

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

لكن المفتاح الجديد لا يتذكر القديم. ولا يخبر المعرّف إن كان البرنامج قد حُدّث في موضعه، أو أُعيد تثبيته، أو نُسخت صورته، أو استُعيدت لقطة قديمة، أو ظهر مدعٍ ثانٍ. القرار الحاسم وقع خارج القطعة الموقعة: جهة ما حكمت بأن حامل المفتاح الجديد يخلف التسجيل السابق، واحتفظت بالأدلة التي تسند ذلك الحكم.

نُشرت المراجعة 00 من draft-mcguinness-oauth-client-instance-id في 28 سبتمبر 2026. وهي مسودة إنترنت فردية يذكر نصها نية Standards Track، من دون حالة فريق عمل أو AD مسؤول أو موعد telechat أو مسار RFC في Datatracker. تحل محل تصميم سابق كان يستخدم assertion منفصلة. أما وثيقة المصادقة الأساسية القائمة على الشهادة فهي عمل في OAuth WG وفي Working Group Last Call، لكن ذلك لا يعني اعتماد هذا الملف الفردي. ولا تثبت المصادر المجمدة وجود تطبيق أو توافق تشغيلي أو نشر أو نتيجة.

إثبات الحيازة لا يجيب عن سؤال الخلافة

تجيب آلية الشهادة الأساسية عن سؤال حاضر: هل يحوز Client Instance مخوّل هذا المفتاح؟ يضيف الملف سؤالاً تاريخياً: هل هذا هو المثيل نفسه الذي قابله Receiver من قبل؟ عند تبدل المفتاح لا تستطيع شهادة جديدة وحدها التمييز بين استمرار تثبيت قائم وولادة تثبيت جديد.

يوفر client_instance_id مقبضاً ثابتاً، لكن هوية المصدر الدقيقة هي الزوج (iss, client_instance_id). تطابق النص تحت مُصدر آخر لا يصنع استمرارية. كما أن Logical Client المشار إليه بـclient_id أوسع من المثيل؛ فقد يضم أجهزة أو حاويات أو عمليات كثيرة. وصاحب الصلاحية الذي يسمح له بفعل شيء ما طبقة أخرى.

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

المعرّف فهرس، أما الدليل ففي التسجيل

يشترط المقترح أن تكون المعرّفات متميزة ومعتمة وغير قابلة للتنبؤ وألا يعاد تخصيصها حتى بعد التقاعد. لا ينبغي أن تضم اسم مضيف أو هوية مستخدم أو خصائص للمثيل. وإذا اتخذت شكل URI فلا دلالة تشغيلية لذلك الشكل؛ يقارنها Receiver كنص دقيق ولا يستنتج منها الحبيبية أو النطاق أو مكان المفتاح.

هذه القيود تحمي المعرّف لكنها لا تولد الاستمرارية. يحتفظ الموثِّق بتسجيل نشط يربط المثيل وLogical Client وReceiver Scope والحبيبية والمفاتيح التي سبق قبولها. وعند التبديل يتحقق من حيازة المفتاح الجديد ومن دليل مصادق عليه يثبت انتقال العهدة المسموح، ثم يسجل الفحوص والنضارة وملاحظات دورة الحياة.

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

لذلك يؤدي حذف سجلات الاستمرارية إلى تسجيل جديد. كما لا يكفي مُدخل ثابت من المنصة لاشتقاق المعرّف، لأنه قد يعيد إحياء قيمة متقاعدة بعد إعادة التثبيت. ما يدوم ليس النص بل آلة حالة محكومة وسجل قراراتها.

Receiver Scope قيد حقيقي لا يراه المستلم في المعرّف

المعرّف مقترن افتراضياً بـReceiver واحد. إلا أن Receiver Scope مدخل إداري عند التسجيل أو الإصدار، وليس وسيط OAuth ولا audience للشهادة. لا يستطيع Receiver فحص النص ومعرفة ما إذا كان النطاق المقصود يخصه.

على الموثِّق إصدار معرّفات مختلفة لكل Receiver إلا عند وجود اتفاق إداري على نطاق مشترك. وعلى العميل استخدام Client Instance Keys مختلفة بين النطاقات المراد فصلها. إعادة استخدام المفتاح قد تعيد الربط بين السجلات حتى لو اختلفت المعرّفات.

إذا عُرضت شهادة مقيدة بالنطاق على Receiver خطأ، فلن يكشف المستلم المخالفة من المعرّف. التنفيذ يعتمد على أن يلتزم العميل والموثِّق بإعداد غير ذاتي الوصف. لذلك يجب أن يسجل إيصال الاستمرارية النطاق المقصود وإصدار السياسة والجهة المسؤولة عن تطبيقهما.

توجد هنا مفاضلة خصوصية لا إعداد مثالي. الفصل الزوجي يقلل ترابط Receivers لكنه يكشف Receiver Scope للموثِّق. النطاق المشترك قد يخفي الوجهة الفردية عن الموثِّق، لكنه يتيح للمستلمين ربط المثيل. والمفاتيح المشتركة وبيانات التطبيق قد تهدم الفصل في الحالتين.

سلطة الموثِّق تنشأ من اقتران محلي

يجب أن يربط Receiver كل Attester Issuer معتمد بمفاتيح التحقق وبـLogical Clients التي يحق له التحدث باسمها. لا يكفي نص iss أو إثبات الحيازة أو metadata ينشرها العميل ليمنح هذه السلطة. وقد يضيف Client Attester Endorsement مدخلاً لخادم التفويض، لكن التحقق المباشر لدى resource server يحتاج إلى اقترانات موثوقة أيضاً.

هناك حكمان لا حكم واحد. الموثِّق يقول إن المدعي استمرار لتسجيل بعينه. وReceiver يقرر إن كان ذلك الموثِّق مخولاً بإصدار هذا القول لهذا العميل وتحت هذه السياسة. توقيع صحيح من مُصدر غير معتمد لا يحقق الشرط. ومُصدر معتمد قد يُخترق أو يبالغ في مستوى الدليل.

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

استمرارية الهوية لا تنقل ربط refresh token

يمكن لهوية التسجيل أن تبقى بعد تغير المفتاح، لكن ذلك لا يعيد تلقائياً ربط refresh token. يظل الربط الافتراضي بالمفتاح السابق ما لم يحدد ملف آخر مخول آلية إعادة الربط.

عند refresh يجب على خادم التفويض التحقق من شرطين منفصلين: تطابق Source Instance Identity مع الهوية المسجلة، وأن إثبات المفتاح الحالي يفي بقيد المنحة أو بملف إعادة ربط مصرح به. الأول يثبت النسب التاريخي؛ الثاني يحدد من يملك استعمال المنحة الآن.

هذا الفصل أوسع من OAuth. الاحتفاظ بصف قاعدة بيانات وتدوير شهادة لا ينقل الصلاحيات حكماً. السؤال الصحيح هو: أي قرار أجاز انتقال بيانات الاعتماد لهذه المنحة، تحت أي سياسة، وما دليل الحيازة الحالية؟

للتعليق عدة ساعات لا ساعة واحدة

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

وقد ينتج عن إعادة التسجيل أو Receiver Scope آخر هوية جديدة لا يستطيع Receiver ربطها بالمعلّقة. لذلك يعتمد الاحتواء على سياسة قبول التسجيلات وعلى التنسيق مع الموثِّق وعلى نوافذ الصلاحية القائمة. وصف «معلق» بلا جهة قرار ووقت نفاذ وتسجيل متأثر ورموز مشمولة وتغطية إشعار ليس سوى حالة محلية.

الخريطة اللاحقة تنشئ سلطة هوية ثانية

يتيح الكائن الاختياري client_instance لمُصدر الرمز نقل سياق تم التحقق منه إلى resource server. وليس ضرورياً أن يكون القيمة الخام التي أصدرها الموثِّق. يرسم مُصدر الرمز Source Instance Identity إلى زوج (iss, id) يملكه ضمن Consumer Scope تحدده audience.

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

هكذا يعمل سجلان: سجل الموثِّق الذي يصل التسجيل بهوية المصدر، وسجل مُصدر الرمز الذي يصل المصدر بالهوية الموجهة للمستهلك. تختلف السلطة ومدة الاحتفاظ في كل منهما. ضياع أحدهما يخلق غياباً مشروعاً للمعلومة؛ اختراع قيمة بديلة يزوّر الاستمرارية.

المشاركة عند الإصدار لا تثبت مقدم الطلب الحالي

لا يمنح Instance Context أي سلطة. من دون consuming profile وsender constraint موثَّق، لا يقول سوى إن المثيل شارك في الحصول على الرمز. لا ينسب طلب HTTP الحالي إليه.

قد يربط DPoP أو mutual TLS أو قيد آخر مقدم الطلب بالمفتاح في الإصدار المباشر. المفتاح المشترك لا يميز مثيلاً بعينه، وbearer token لا يقدم هذا الإثبات. إذا كانت النسبة مطلوبة وتعذر توفير الرابط، ينبغي حذف السياق وعلى المستهلك رفض الطلب حين تكون المعلومة إلزامية.

يزيد token exchange صعوبة المصدر. التحقق من input token يصادق أقوال مُصدره، لا كل سلطة أقدم مذكورة داخله. يجب أن يحدد الملف المستهلك ما إذا كان السياق يمثل المثيل الحالي أو مثيلاً upstream، وكيف يثبت الارتباط والحفظ وإعادة الرسم. السياق مرجع إلى مثيل واحد، لا actor chain ولا رمزاً مستقلاً.

شكل الإيصال القابل للمساءلة

يبدأ الإيصال بهوية Attester Issuer ومفتاح التحقق وLogical Client والتسجيل والحبيبية وReceiver Scope وإصدار سياسة الثقة. ولكل انتقال يربط بصمتي المفتاحين، وحدث دورة الحياة، ودليل العهدة، وفحوص الاستمرارية، والنضارة، والوقت، والقرار: احتفاظ أو تسجيل جديد أو تقاعد أو تعليق أو fork.

يسجل للمنحة Source Instance Identity منفصلة عن ربط المفتاح وعن أي ملف إعادة ربط. وللاستهلاك يسجل مُصدر الرمز ومدخل الخريطة وInstance Context وConsumer Scope وaudience وحقبة الاحتفاظ ومصدر الحفظ أو إعادة الرسم. ولكل طلب يسجل sender constraint وقرار التفويض المحلي.

ثم يربط العملية المحمية بالنتيجة المرصودة. نجاح تدوير المفتاح يغلق انتقال الاستمرارية الذي يسميه فقط؛ لا يغلق سلامة البرنامج الحالية ولا التفويض ولا هوية المقدم ولا التنفيذ ولا الأثر.