Summary

  • قُدمت مسودة Selo الفردية في 31 أكتوبر بوصفها تصوراً لاتفاقات وصول بين كيانات قانونية يتفاوض عليها وكلاؤها. لم تصبح بروتوكولاً معتمداً من IETF.
  • يفحص برنامج حتمي مستقل حدود التفويض الموقع من مالك كل كيان قبل التوقيع؛ ولا يبدأ الوصول إلى بيانات الإنتاج إلا بعد توقيع الطرفين وتأكيد اختبار التبادل بينهما.
  • يتطلب تغيير بيانات الدفع نسخة جديدة موقعة، وموافقة شخص ذي دور مالي، وإشعاراً مباشراً يتجاوز الوكيلين، وفترة يمكن خلالها الإلغاء، وتأكيداً من إنسان لدى الدافع قبل أول تحويل إلى البيانات الجديدة.

الحساب الجديد ليس مجرد خانة جديدة

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

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

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

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

لا تصف المسودة عملية احتيال وقعت بالفعل، ولا تنقل Selo الأموال بنفسها. يسجلها متتبع IETF مسودة فردية بلا مكانة معيارية رسمية. سؤالها العملي واضح: إذا كانت الآلات تعقد الصلات بين الشركات، فمن يستطيع تغيير المستفيد المالي قبل أن يغادر أول مبلغ؟

المصادر الرسمية