الخلاصة

  • أُعلنت مراجعة VCAP-02 في 4 سبتمبر بصفتها مسودة إنترنت فردية، من دون اعتماد من IETF أو مكانة معيارية رسمية أو مسار RFC أو مدير منطقة مسؤول.
  • أضافت المراجعة قسماً يعترف بأن السوق يتحكم عملياً في نتائج التسوية حين يختار جهات التحقق، ويفرض سجلات للمفاتيح والقدرات والنزاع والتغيير.
  • مع ذلك، يرسل مقدم الخدمة service_delivery ويمكنه تضمين auto_approve، المعرّف بأنه تخطٍ للتحقق الآلي لأن مقدم الخدمة يشهد لنفسه.
  • لا تقول المسودة من يقبل الإعفاء، وأي بند تعاقدي يجيزه، ومن يوقع رسالة النتيجة، وأي اختبارات تبقى، وكيف ينتهي القرار أو يُعترض عليه.
  • يلزم قبل تحريك الأموال إيصال إعفاء يربط المقترح بسلطة القبول والأساس التعاقدي والنطاق والحدود والانتهاء والموقع والأدلة المتعارضة ومسار النزاع والحالة النهائية.

الإصلاح الجديد سمّى السلطة في المسار المعتاد

يثبت إعلان IETF واقعة محدودة: إتاحة مسودة من ثلاثين صفحة كتبها Ben Stone في 4 سبتمبر. وتضع صفحة Datatracker الحد المؤسسي. إنها مسودة فردية نشطة يستطيع أي شخص تقديم مثلها، وليست مؤيدة من IETF ولا تملك مكانة رسمية في عملية المعايير أو مسار RFC أو مدير منطقة مسؤولاً. أما «Informational» فهو وضع مقصود في رأس المسودة، لا نتيجة مؤسسية مكتسبة.

داخل هذه الحدود، تصف المراجعة 02 سلسلة ذات أثر مالي. يتفق طالب الخدمة ومقدمها على العمل والثمن، وتحجز السوق الأموال، ويسلم المقدم الناتج، وتفحصه جهة تحقق ثم ترسل verification_callback. تنقل passed=true الحالة إلى VERIFIED والإفراج، بينما تنقل false المسار إلى FAILED والاسترداد. وتصف المسودة هذه الرسالة بأنها الأهم لأنها تطلق التسوية.

يبين الفرق الرسمي إضافة جوهرية مقارنة بـالمراجعة 01: قسم مساءلة جهة التحقق. يقول إن السوق تتحكم فعلياً في نتيجة التسوية عندما تختار من يتحقق. وقبل قبول النتيجة، يجب عليها تسجيل مفتاح Ed25519 أو طريقة التحقق والثقة بها، وحفظ القدرات المعلنة، وتحديد مسار تصعيد عند الاعتراض. كما يجب تأريخ التسجيل وتدوير المفتاح وإلغاء التسجيل والاحتفاظ بها مع سجل التسوية.

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

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

من يطلب التخطي هو الطرف المستفيد من الدفع

يرسل مقدم الخدمة service_delivery حين يدعي إكمال العمل. وتحمل الرسالة وصف التسليم وآثاره وإرشادات مثل الرابط والمحدد والنص المتوقع وتغير البصمة. وفي الكائن نفسه يوجد auto_approve. إذا كان true، يُتخطى التحقق الآلي ويُقبل إقرار المقدم الذاتي، وفق الوصف القصير.

يوضح مخطط JSON للتسليم المرتبط بالمسودة أن إرشادات المقدم قد «تتجاوز أو تكمل» إرشادات الطالب. والقيمة الافتراضية للحقل false. غير أن القيمة الافتراضية ليست تفويضاً؛ فهي تحدد ما يفعله المحلل حين يغيب الحقل، ولا تحدد من يملك جعله true أو موافقة من تمنحه أثراً.

لا يظهر الاسم auto_approve في كل من النصوص الثابتة -00 و-01 و-02 إلا مرتين: مرة في نموذج الرسالة ومرة في جدول الإرشادات. لا توجد قاعدة تحدد صاحب الاقتراح المؤهل، أو جهة القبول، أو بند الاتفاق، أو سقف القيمة والخطر، أو الاختبارات المتبقية، أو الانتهاء والإلغاء والتعارض وسجل القرار.

ماذا تفعل السوق بقيمة true غير معترف بها؟ هل تتجاهلها، أم ترفضها، أم تبقي المال HELD، أم تطلب موافقة الطالب، أم تحولها إلى إنسان؟ كلها سياسات ممكنة. لا تستخرج تطبيقات مستقلة جواباً واحداً من النص الحالي.

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

أين تأتي رسالة النتيجة إذا لم يحدث تحقق؟

في المسار المعتاد، تحمل رسالة النتيجة معرّف التحقق وpassed وبصمة الدليل وتوقيعه ومعرّف مفتاح جهة التحقق وسجل الإجراءات ووقت الإتمام. ثم ينسخ سجل التسوية المعرّف والبصمة والتوقيع. عند تخطي المحرك الآلي، من يشغل دور جهة التحقق؟

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

لا تستطيع الخوارزمية أن توزع الصلاحيات. تحسب VCAP-02 بصمة SHA-256 لحزمة معيارية وتوقع بـEd25519 جسماً يشمل مراجع التحقق والتفاوض والحجز والنتيجة والبصمة والمفتاح والوقت. وتحدد RFC 8032 طريقة اختبار التوقيع بالمفتاح العام. وتحصر VCAP الاستنتاج بدقة: البصمة تكشف تغيير المحتوى، والتوقيع ينسب الدليل إلى جهة تحقق مخولة. لا يثبت أي منهما موافقة طالب الخدمة على الإعفاء.

كما أن الذرية وعدم تكرار الأثر يحميان سؤالاً آخر. يمنع compare-and-swap الإفراج والاسترداد معاً، ويمنع التكرار تسوية الحجز مرتين. يضمنان نهاية واحدة، لا شرعية الاستثناء الذي اختارها.

ويظهر مسار انتهاء المهلة كيف يمكن تصميم الاستثناء. عند عدم اكتمال التحقق خلال 1,800 ثانية افتراضياً، يجب أن تبقى الأموال HELD، وينبغي إنشاء مراجعة بشرية، ويجب على إنسان اتخاذ القرار النهائي. ثم يصدر callback عادياً فيه سطر واحد يسجل القرار وبصمة وتوقيع. يمكن لاحقاً معرفة من قرر وكيف. لا يملك auto_approve هذا الجسر.

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

المواد القابلة للتنفيذ تحمل تحذيراً ثانياً

لم تكن المخططات العامة متزامنة عند موعد القطع. ظل مخطط verification_callback يطلب HMAC-SHA256 بصيغة سداسية، ويقبل vcap_version 1.0 فقط، ولا يحتوي verifier_key_id. أما المراجعة 02 فتطلب Ed25519 وBase64 ومعرّف المفتاح. ويبين سجل المستودع أن المخططات المرتبطة لم تتحدث مع تقديم سبتمبر.

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

وتصحح المراجعة أيضاً علاقتها بـAP2. يحدد AP2 التفويض والأدوار ودليل الدفع، بينما لا تفترض VCAP-02 أنه يحدد حالات الحجز والخصم والاسترداد والتسوية. لذلك لا يمكن إحالة سلطة auto_approve الغائبة إلى البروتوكول الأعلى ضمناً.

إيصال إعفاء قبل تحريك المال

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

يجب أن يوجد الإيصال قبل التسوية. إذا تعذر التحقق من البند أو سلطة القبول، ترفض السوق الإرشاد أو تبقي المال HELD. لا تستنتج موافقة جديدة على ترك الفحص من قبول عام سابق للتفاوض.

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

المصادر

  1. إعلان IETF عن مراجعة VCAP-02
  2. حالة الوثيقة في IETF Datatracker
  3. مراجعة VCAP-02
  4. مراجعة VCAP-01
  5. الفرق الرسمي بين 01 و02
  6. مخطط JSON لرسالة service_delivery
  7. مخطط JSON لرسالة verification_callback
  8. سجل مستودع مواصفة VCAP
  9. RFC 8032 — EdDSA
  10. مواصفة Google Agent Payments Protocol
  11. Heng Lu عن أولوية الشفرة العاملة
  12. Heng Lu عن الحد الأدنى المشترك والقرار المحلي