Deep Dive: بروتوكول Mastercard Verifiable Intent مقابل Visa Trusted Agent Protocol

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

وهذا يخلق ثلاث إخفاقات ثقة ملموسة تظهر كتكاليف تشغيلية:

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

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

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

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

أماكن الاختلاف في موضع البنية التحتية ونموذج الأدلة

I أرى التباين بين “دليل سلسلة الاعتمادات” مقابل “شهادة حافة HTTP”.

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

أما بروتوكول الوكيل الموثوق من فيزا فهو مُنظم كإشارة تفاعل في الوقت الحقيقي للتجار وطبقات حمايتهم. العنصر الأساسي هو سياق طلب HTTP موقع، بالإضافة إلى كائنات مرتبطة للتمييز بين المستهلك وبيانات حاوية الدفع. يركز على “هل هذا وكيل موثوق يتفاعل مع موقعي الإلكتروني الآن”، وليس “هل يمكن للمصدر أن يحكم لاحقًا على التفويض المفوض”.

المرتكزات الثقة مختلفة.

نية التحقق من الصحة تعتمد على مصدر اعتماد بيانات الدفع (مؤسسة مالية أو شبكة في دور المصدر) الذي يصدر الطبقة 1، ثم توقيع المستخدم على الطبقة 2، ثم توقيع الوكيل على الطبقة 3 باستخدام مفاتيح مرتبطة عبر دلالات cnf. هذا دليل على التفويض كسلسلة تشفيرية.

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

الوضعية الخصوصية أيضًا مختلفة من الناحية الهيكلية.

نية التحقق تستخدم SD-JWT للكشف الانتقائي لجعل أقل قدر من الكشف هو الخاصية الأساسية: يطلع التاجر على إعلانات تفويض الدفع؛ الشبكة ترى إعلانات تفويض الدفع؛ الربط بين الطبقة 3 مصمم بشكل صريح للحفاظ على ذلك الحد.

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

إذا قمت بتلخيص ذلك في سطر واحد: نية التحقق مصممة للتدقيق عبر الأدوار والزمن؛ بروتوكول الوكيل الموثوق مصمم للتفاعل الآمن والتمييز عند حدود التاجر.

واقعيات التكامل لمطوري التكنولوجيا المالية

هذه الحلول ليست متعارضة. فهي تعالج حالات فشل مختلفة ستتواجد معًا في الإنتاج.

إذا كنت أطور بنية تحتية للتاجر، فإن بروتوكول الوكيل الموثوق يتوافق مع نتائج هندسية فورية: التحقق من توقيعات طلب RFC 9421 على الحافة، استرجاع المفاتيح وتخزينها، تتبع إعادة تشغيل nonce، ومعالج داخلي يقرر ما إذا كان يجب اعتبار الجلسة الواردة “نية تجارة الوكيل” استنادًا إلى الوسم.

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

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

التكلفة غير الواضحة في التكامل هي إدارة المفاتيح وساحات التوقيع.

نية التحقق تفترض مفتاح توقيع المستخدم المرتبط في الطبقة 1 والذي يُستخدم لتوقيع الطبقة 2. يناقش المعيار نماذج نشر حيث “يخلق المستخدم L2” يمكن أن يعني نظامًا مخولًا يحمل مفتاح المستخدم الخاص، ويعتبر تعريض مفتاح المستخدم بمثابة استيلاء كامل على الحساب طوال عمر اعتماد الطبقة 1.

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

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

شهادة TAP تحل مشكلة “دعني أتصفح وأتفاعل دون أن يتم حظري” وتوفر قناة للتجار لطلب معلومات إضافية أو دفع مقابل الوصول إلى موارد مثل المراجعات.

دليل التفويض من نوع VI يحل مشكلة “دعني أصرح بشكل مستقل ضمن قيود يحددها المستخدم وأحفظ الدليل للشبكة ومسار النزاع”، مع ربط صريح بين عمليات الدفع والتفويض.

الموقف المعياري متقارب حتى لو كانت الأدلة مختلفة. تقول ماستر كارد صراحة إن نية التحقق تعتمد على معايير معتمدة على نطاق واسع تشمل FIDO Alliance، EMVCo، IETF، وW3C.

وتؤكد فيزا على التوافق مع هيئات المعايير مثل IETF، OpenID Foundation، وEMVCo، وتصف بروتوكول الوكيل الموثوق بأنه مبني على معيار توقيعات رسائل HTTP ومتوافق مع Web Bot Auth.