الخلاصة

  • غيّرت المراجعة 01 من Using KYAPay Tokens، المنشورة في 2 أكتوبر 2026، اسم الطرف المستهلك للرمز من «المتحقق» إلى «المستلم»، ونصت على أن التعريف لا يساوي القبول. فالرمز الصحيح يوفر سياقاً موثقاً، بينما يظل السماح أو التقييد أو طلب تحقق أقوى أو الرفض قراراً محلياً.
  • لا يثبت نجاح التحقق كل ما يأتي بعده: رمز الحامل لا يثبت حيازة مفتاح خاص، والتفويض عند الإصدار لا يثبت استمرار سيطرة الإنسان، وبيانات PAY لا تثبت قبول التاجر أو التسوية النهائية.

أكثر ما يكشف بنية KYAPay ليس claim جديداً، بل تغيير اسم الدور الذي يقرأ الرمز. ففي draft-skyfire-oauth-using-kyapay-tokens-01 لم يعد هذا الطرف مجرد verifier؛ أصبح recipient. والفرق هو أن التحقق اختبار، أما الاستلام فهو موقع تظل فيه سلطة فعلية لم تُحسم بعد.

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

ينظم KYA ادعاءات تخص الإنسان صاحب التفويض ومنصة تشغيل الوكيل ومثيل الوكيل نفسه، ويضيف PAY سياق الدفع. هذه الإحداثيات أفضل من تخمين الفاعل من عنوان IP أو User-Agent. لكنها تجيب عن سؤال: «ماذا تقول جهة الإصدار عمن يقف خلف الطلب؟» ولا تجيب عن سؤال: «ما الذي يجب أن يفعله تطبيقي؟»

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

كذلك يجب ألا تُمنح الوثيقتان مكانة لم تحصلا عليها. فهما مسودتا إنترنت فرديتان، ولا تسجل لقطات Datatracker المحفوظة stream أو مستوى معيار أو اعتماد مجموعة عمل. قائمة OAuth مكان للنقاش وليست دليلاً على الإجماع. وطلبات تسجيل حقل HTTP وclaims في JWT تبقى مقترحات حتى تظهر في سجلات IANA الحية.

مسار التحقق سلسلة من نتائج مستقلة. يقرر المستلم أولاً أي جهات إصدار يثق بها، ثم يفحص رأس JOSE والتوقيع وexp وiat وjti وaud والبيئة. ويميز نوع الرمز ومستوى الضمان المتصل بالإنسان والمنصة والوكيل. وجود ترويسة KYAPay-Token وحده ليس دليلاً على حضور إنسان الآن.

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

تسمح المراجعة 02 من صيغة الرمز بـcnf للإشارة إلى مادة مفتاح تأكيد. وقد يدعم ذلك تقييد الرمز بالمرسل عندما يطلب البروتوكول المحيط proof فعلياً ويتحقق المستلم منه. أما ذكر المفتاح داخل كائن موقّع فليس هو فعل الإثبات. يجب حفظ نتيجة التوقيع ونتيجة حيازة المفتاح كطبقتين منفصلتين.

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

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

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

لذلك يحفظ الإيصال القابل للتدقيق نسخة المسودة والملف الدقيقين؛ جهة الإصدار ومجموعة المفاتيح؛ دليل الهوية ومستوى الضمان؛ hash ثابتاً للرمز؛ نتائج التوقيع والclaims؛ الجمهور والبيئة؛ قرار منع الإعادة؛ bearer أو proof المفتاح؛ نسخة السياسة ونتيجة التحقق الإضافي؛ ثم فعل التطبيق النهائي. وفي الدفع تبقى مراجع التفويض والمقاصة والتسوية والعكس سجلات مستقلة.

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

إذن كلمة recipient تصحح موقع السلطة. الجهة تُصدر الادعاء، والرمز ينقله، والمتحقق يفحصه؛ لكن المستلم يدير واجهته، والتطبيق يسجل ما فعله بالفعل.

المصادر