خادم التحكم في الوصول (ACS) لمعيار EMV 3DS: مفاتيح المرور (Passkeys) و FIDO و SPC

يشهد مجال مصادقة الدفع عبر الإنترنت تحولًا كبيرًا، مدفوعًا بالحاجة المزدوجة لتعزيز الأمان ضد عمليات الاحتيال المتطورة وتحسين تجربة المستخدم لتقليل العقبات والتخلي عن عربات التسوق. يعمل بروتوكول EMV® 3-D Secure (3DS)، وخاصة إصداراته الأحدث (EMV 3DS 2.x)، بمثابة التكنولوجيا الأساسية لمصادقة المعاملات التي لا تتطلب وجود بطاقة فعلية (CNP) على مستوى العالم. يسهل هذا البروتوكول، الذي تديره EMVCo، تبادل البيانات بين التجار والجهات المصدرة للبطاقات (عبر خادم التحكم في الوصول الخاص بهم - ACS) ومجال التشغيل البيني (خوادم الدليل التي تشغلها أنظمة الدفع) للتحقق من هوية حامل البطاقة.

في هذا الإطار، يبرز تطوران تقنيان رئيسيان مرتبطان بمعايير تحالف FIDO (Fast Identity Online):

1. استخدام بيانات مصادقة FIDO التي تم إنشاؤها أثناء تفاعلات المستخدم السابقة (مثل تسجيل الدخول لدى التاجر) لإثراء تقييم المخاطر في المسار السلس لبروتوكول EMV 3DS.
2. دمج تأكيد الدفع الآمن (Secure Payment Confirmation) (SPC)، وهو معيار ويب من W3C مبني على FIDO/WebAuthn، كطريقة "تحدي" مبسطة ومقاومة للتصيد الاحتيالي ضمن تدفق EMV 3DS.

يقدم هذا المقال نظرة عامة على السوق العالمي لحلول خادم التحكم في الوصول (ACS) لمعيار EMV 3DS المقدمة للبنوك المصدرة للبطاقات. ويحدد الموردين الرئيسيين ويحاول تقييم دعمهم الحالي لكل من هياكل بيانات FIDO (غير SPC) وتأكيد الدفع الآمن (Secure Payment Confirmation) (SPC) لمسارات التحدي. علاوة على ذلك، يوضح الآلية التي يمكن من خلالها للجهات المصدرة الاستفادة من مفاتيح المرور (Passkeys) الخاصة بها القائمة على FIDO للتحقق التشفيري ضمن مسار تحدي 3DS عبر SPC، ويناقش قابلية تطبيق هذا المعيار عالميًا.

يعمل EMV 3DS بشكل أساسي من خلال مسارين مختلفين للمصادقة:

• المسار السلس (Frictionless Flow): هذا هو المسار المفضل، ويهدف إلى توفير تجربة مستخدم سلسة. يقوم خادم ACS التابع للجهة المصدرة بإجراء تقييم للمخاطر بناءً على مجموعة غنية من البيانات التي يتم تبادلها أثناء بدء المعاملة (عبر طلب المصادقة، أو رسالة AReq). تتضمن هذه البيانات تفاصيل المعاملة، ومعلومات التاجر، وخصائص الجهاز، وبيانات المتصفح (التي قد يتم جمعها عبر 3DSMethod JavaScript)، وربما معلومات المصادقة السابقة. إذا اعتبرت المخاطر منخفضة، تتم مصادقة المعاملة دون الحاجة إلى أي تفاعل مباشر أو "تحدي" من حامل البطاقة. يمثل هذا المسار غالبية معاملات 3DS، خاصة عندما تكون محركات تقييم المخاطر مضبوطة جيدًا.
• مسار التحدي (Challenge Flow): إذا قرر خادم ACS أن مخاطر المعاملة عالية، أو إذا كانت اللوائح تفرض ذلك (مثل PSD2 SCA في أوروبا) أو سياسة الجهة المصدرة، يتم تحدي حامل البطاقة بشكل فعال للتحقق من هويته. تشمل طرق التحدي التقليدية رموز المرور لمرة واحدة (OTP) المرسلة عبر الرسائل القصيرة، أو الأسئلة القائمة على المعرفة، أو المصادقة خارج النطاق (OOB) عبر تطبيق بنكي. الهدف من إصدارات 3DS الأحدث والتقنيات ذات الصلة مثل SPC هو جعل مسار التحدي هذا أكثر أمانًا وأقل تعقيدًا من الأساليب القديمة.

تعاونت EMVCo وتحالف FIDO لتحديد طريقة موحدة يمكن للتجار من خلالها تمرير معلومات حول مصادقات FIDO السابقة (حيث كان التاجر هو الطرف المعتمد، على سبيل المثال، أثناء تسجيل دخول المستخدم) إلى خادم ACS التابع للجهة المصدرة ضمن رسالة AReq القياسية في 3DS. هذه الآلية، التي تم دعمها لأول مرة في EMV 3DS v2.1، تستفيد من حقول محددة داخل AReq، وبشكل أساسي بنية threeDSRequestorAuthenticationInfo، التي تحتوي على حقول فرعية مثل threeDSRequestorAuthenticationData.

تحدد المذكرة الفنية لتحالف FIDO والورقة البيضاء ذات الصلة من EMVCo بنية JSON لحقل threeDSRequestorAuthenticationData عند نقل تفاصيل مصادقة FIDO السابقة. يتضمن كائن JSON هذا تفاصيل مثل وقت المصادقة (authTime)، ومعرف الطرف المعتمد في FIDO (rpId أو appId)، ومعلومات حول أداة (أدوات) المصادقة المستخدمة، بما في ذلك المفتاح العام، وAAGUID/AAID، ومؤشرات وجود المستخدم (UP) وتحقق المستخدم (UV).

المنطق وراء ذلك هو أنه إذا أجرى التاجر مؤخرًا مصادقة FIDO قوية (على سبيل المثال، باستخدام القياسات الحيوية أو مفتاح مرور) لجلسة المستخدم التي بدأت عملية الشراء، يمكن أن تكون هذه المعلومات بمثابة إشارة خطر إضافية قيمة لخادم ACS التابع للجهة المصدرة. من خلال تلقي ومعالجة بيانات FIDO الموحدة هذه، يمكن لخادم ACS أن يكتسب ثقة أكبر في شرعية المعاملة، مما يزيد من احتمالية الموافقة السلسة ويقلل من الحاجة إلى تحدٍ منفصل. من المهم ملاحظة أنه في هذا السيناريو، يكون التاجر هو الطرف المعتمد (RP) في FIDO، وتستهلك الجهة المصدرة هذه البيانات كمدخل لمحرك تقييم المخاطر الخاص بها؛ ولا تتحقق الجهة المصدرة تشفيريًا من تأكيد FIDO نفسه ضمن هذا المسار السلس. يحتفظ خادم ACS بخيار تجاهل هذه البيانات إذا لم يكن مهيأً لمعالجتها it.

يمثل تأكيد الدفع الآمن (Secure Payment Confirmation) (SPC) تكاملاً مميزًا لمعايير FIDO ضمن مسار التحدي في EMV 3DS flow. إن SPC هو معيار ويب من W3C، تم تطويره بالتعاون مع FIDO و EMVCo، ومبني على WebAuthn. وهو مدعوم رسميًا ضمن EMV 3DS بدءًا من الإصدار 2.3.

عند استخدام SPC كطريقة تحدي:

1. تعمل الجهة المصدرة (أو طرف مفوض صراحة من قبل الجهة المصدرة، مثل نظام دفع) كطرف معتمد (Relying Party) في FIDO (RP). وهذا يختلف جوهريًا عن تدفق بيانات FIDO (غير SPC) الموصوف سابقًا، حيث يعمل التاجر عادةً كـ RP لأغراض تسجيل الدخول/المصادقة الخاصة به purposes.
2. أثناء تحدي 3DS، يشير خادم ACS إلى الحاجة إلى SPC ويوفر معرفات بيانات اعتماد FIDO اللازمة وتحدي تشفيري للتاجر/خادم 3DS.
3. يستدعي نظام التاجر واجهة برمجة تطبيقات SPC في المتصفح، ويعرض تفاصيل المعاملة (المبلغ، العملة، المستفيد، الأداة) للمستخدم في مربع حوار آمن يتحكم فيه المتصفح.
4. يقوم المستخدم بالمصادقة باستخدام أداة المصادقة الخاصة به في FIDO (مثل القياسات الحيوية للجهاز، أو رقم التعريف الشخصي، أو مفتاح الأمان)، والتي توقع على تفاصيل المعاملة والتحدي باستخدام المفتاح الخاص المرتبط بمفتاح المرور المسجل لدى الجهة المصدرة.
5. يتم تمرير تأكيد FIDO الناتج (إثبات تشفيري للمصادقة والموافقة) مرة أخرى عبر بروتوكول 3DS (عادةً عبر رسالة AReq ثانية) إلى خادم ACS التابع للجهة المصدرة.
6. يقوم خادم ACS، بصفته الطرف المعتمد، بالتحقق التشفيري من التأكيد باستخدام المفتاح العام المقابل، مما يؤكد هوية حامل البطاقة وموافقته على تفاصيل المعاملة المحددة.

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

يقدم المساران المزدوجان لتكامل FIDO - أحدهما يستفيد من بيانات مصادقة التاجر السابقة لتقييم المخاطر السلس، والآخر يستخدم بيانات الاعتماد التي تديرها الجهة المصدرة لتحدي مباشر قائم على FIDO عبر SPC - نهجين متميزين لتعزيز الأمان وتجربة المستخدم ضمن إطار EMV 3DS. يعد فهم دعم الموردين لكل منهما أمرًا بالغ الأهمية للجهات المصدرة ومقدمي خدمات الدفع الذين يخططون لاستراتيجيات المصادقة الخاصة بهم.

يحلل هذا القسم قدرات الموردين العالميين لحلول EMV 3DS ACS، مع التركيز على تواجدهم في السوق ودعمهم لبيانات FIDO (غير SPC) وتأكيد الدفع الآمن (SPC). يصعب الحصول على أرقام دقيقة للحصة السوقية علنًا؛ لذلك، يتم تقييم التواجد بناءً على ادعاءات الموردين والشهادات والشراكات والانتشار الجغرافي وتقارير السوق.

• التواجد في السوق: تضع Entersekt نفسها، خاصة بعد استحواذها على أعمال برمجيات 3DS من Modirum في ديسمبر 2023، كمزود عالمي رائد لحلول EMV 3DS، بهدف الوصول إلى مركز ضمن الخمسة الأوائل في السوق. كانت Modirum تتمتع بخبرة تزيد عن 20 عامًا في 3DS. تسلط Entersekt الضوء على النمو القياسي المدفوع بالعملاء الجدد، خاصة في أمريكا الشمالية، والشراكات الاستراتيجية، بما في ذلك علاقة موسعة مع Mastercard. تدعي الشركة أنها تؤمن أكثر من 2.5 مليار معاملة سنويًا (اعتبارًا من السنة المالية 24) وتحتل المرتبة الأولى في منع الاستيلاء على الحسابات (ATO) في القطاع المصرفي حسب Liminal. يتوفر خادم ACS الخاص بها كخدمة مستضافة (من قبل Entersekt أو العميل) أو محليًا. تخدم الشركة الجهات المصدرة والمعالجين عالميًا.
• دعم بيانات FIDO غير SPC (للمسار السلس): تؤكد Entersekt على مصادقتها المدركة للسياق (Context Aware™ Authentication)، وتحليلات الأجهزة والسلوك لإشارات المخاطر، والتكامل مع مختلف خدمات تقييم المخاطر. خادم ACS الخاص بها معتمد من FIDO EMVCo 2.2. بينما يسلطون الضوء على الاستفادة من بيانات المخاطر والذكاء السلوكي لـ RBA، لا يوجد تأكيد صريح في المواد المتاحة عبر الإنترنت على معالجة بيانات إثبات FIDO الموحدة من مصادقات التجار السابقة ضمن حقل threeDSRequestorAuthenticationInfo لتحسين المسار السلس. ومع ذلك، فإن تركيزهم على المصادقة المتقدمة وإشارات المخاطر يوحي بوجود هذه القدرة.
• دعم SPC (للتحدي): تشير مؤشرات قوية إلى أن Entersekt تدعم SPC. قدمت Modirum، التي استحوذت Entersekt على أعمال 3DS الخاصة بها، مكونات لمشروع Visa التجريبي لـ SPC باستخدام 3DS 2.2 مع امتدادات. تدرج Entersekt صراحةً دعم الامتثال لـ SPC كجزء من قدراتها على الامتثال التنظيمي. يدعم خادم ACS الخاص بها المصادقة البيومترية، وهو معتمد لـ EMV 3DS 2.2، ومن المرجح أنه يدمج القدرات من مشاركة Modirum في المشروع التجريبي. إن الجمع بين الاستحواذ على Modirum، والإشارة الصريحة إلى الامتثال لـ SPC، وشهادة FIDO يشير بقوة إلى دعم SPC في عرضهم الحالي.

• التواجد في السوق: تعد Arcot من Broadcom لاعبًا أساسيًا في سوق 3DS، حيث شاركت في اختراع البروتوكول الأصلي مع Visa. تضع الشركة نفسها كرائد عالمي معترف به، تخدم أكثر من 5000 مؤسسة مالية في جميع أنحاء العالم وتعالج المعاملات من 229 دولة. تؤكد شبكة Arcot الخاصة بها على نهج بيانات الكونسورتيوم الواسع (تدعي وجود أكثر من 600 مليون توقيع جهاز، و 150 تريليون نقطة بيانات) لتشغيل محركات تقييم الاحتيال والمخاطر engines. لديهم حضور قوي في أوروبا وأستراليا وأمريكا الشمالية.
• دعم بيانات FIDO غير SPC (للمسار السلس): تركز Broadcom بشدة على ثراء شبكة بياناتها واستخدام الذكاء الاصطناعي/الشبكات العصبية للكشف عن الاحتيال وتقييم المخاطر، متجاوزة عناصر بيانات EMV 3DS القياسية. يذكرون صراحة أن حلهم يستفيد من البيانات المتدفقة عبر العديد من الجهات المصدرة ويدمج البيانات الرقمية مثل بيانات الجهاز والموقع الجغرافي. على الرغم من عدم ذكر معالجة بنية JSON المحددة لـ FIDO من threeDSRequestorAuthenticationData بشكل صريح، فإن تركيزهم على استيعاب نقاط بيانات متنوعة لـ RBA يوحي بقوة بأنهم يمكنهم استهلاك هذه البيانات إذا تم توفيرها، بما يتماشى مع هدف إرشادات EMVCo/FIDO. تهدف منصتهم إلى زيادة الموافقات السلسة إلى أقصى حد من خلال تقييم المخاطر الفائق.
• دعم SPC (للتحدي): تؤكد وثائق Broadcom دعم أدوات مصادقة FIDO (مفتاح الأمان، القياسات الحيوية، Passkey) ضمن مجموعة VIP Authentication Hub / Identity Security الأوسع suite. يدعم خادم 3DS ACS الخاص بهم طرق تحدي مختلفة بما في ذلك OTPs والإشعارات الفورية، ويذكرون دعم القياسات الحيوية. كما يقدمون قدرات المصادقة المفوضة وقد أدخلوا ميزات تقييم المخاطر بعد التحدي. ومع ذلك، فإن التأكيد الصريح على أن منتج EMV 3DS ACS الخاص بهم يدعم حاليًا SPC كطريقة تحدي محددة (تتطلب قدرات EMV 3DS v2.3+ وتدفق AReq المزدوج) غائب في الوثائق المقدمة. على الرغم من أنهم لاعب رئيسي قادر على الأرجح على تنفيذه، إلا أن المواد المتاحة للجمهور حاليًا تركز بشكل أكبر على محرك RBA الخاص بهم وطرق التحدي التقليدية/خارج النطاق methods.

• التواجد في السوق: تضع Netcetera نفسها كلاعب دولي مهم في مجال المدفوعات، وهي قوية بشكل خاص في أوروبا والشرق الأوسط. يذكرون أن خادم ACS الخاص بهم يستخدمه أكثر من 800 بنك/جهة مصدرة، ويؤمن أكثر من 50 مليون بطاقة في جميع أنحاء العالم. يؤكدون على الشهادات مع جميع شبكات البطاقات الرئيسية (Visa، Mastercard، Amex، Discover، JCB، UnionPay، إلخ) والامتثال لـ PCI compliance. كانوا بشكل ملحوظ أول مورد ACS في جميع أنحاء العالم يحصل على شهادة EMV 3DS 2.3.1.
• دعم بيانات FIDO غير SPC (للمسار السلس): تسلط وثائق Netcetera الضوء على أهمية البيانات التي يتم جمعها عبر 3DSMethod لتقييم مخاطر ACS لزيادة المصادقة السلسة. يقدمون التكامل مع أدوات المخاطر. ومع ذلك، لا يتم ذكر تأكيد محدد لمعالجة بيانات مصادقة FIDO السابقة من التجار (من threeDSRequestorAuthenticationInfo) لتقييم المخاطر بشكل صريح في المواد التي تمت مراجعتها.
• دعم SPC (للتحدي): تظهر Netcetera دعمًا قويًا لـ SPC. كانوا أول مورد معتمد عالميًا لـ EMV 3DS 2.3.1، وهو الإصدار الذي يدمج SPC. شاركوا في مشروع Visa التجريبي لـ SPC، حيث قدموا مكونات v2.3.1. تحدد وثائق منتجاتهم صراحةً SPC. لقد أجروا ندوات عبر الإنترنت لمناقشة تكامل FIDO و SPC integration ونشروا مقالات تسلط الضوء على فوائد SPC. هذا المزيج من الشهادات والمشاركة في المشاريع التجريبية والوثائق الصريحة يؤكد دعمهم لتحديات SPC.

• التواجد في السوق: تضع Worldline نفسها كرائد أوروبي في خدمات الدفع والمعاملات ولاعب عالمي رئيسي (تدعي أنها تحتل المرتبة الرابعة عالميًا في مجال المدفوعات). تعالج الشركة مليارات المعاملات سنويًا وتؤكد على الامتثال المضمون، ومكافحة الاحتيال باستخدام الذكاء الاصطناعي/التعلم الآلي، وقابلية التوسع. يُذكر أن خادم ACS الخاص بها معتمد من EMV 3DS ومتوافق مع الأنظمة الرئيسية (Visa Secure، Mastercard Identity Check) و PSD2. أفادوا بمعالجة أكثر من 2.4 مليار معاملة 3DS سنويًا لأكثر من 100 جهة مصدرة.
• دعم بيانات FIDO غير SPC (للمسار السلس): يتضمن عرض ACS من Worldline محرك قواعد RBA يسمح للجهات المصدرة بتكوين مسارات سلسة أو تحدي بناءً على المخاطر. يستفيد حلهم الأوسع "Trusted Authentication" من ذكاء الجهاز والتحليل السلوكي. بينما يدعمون FIDO بشكل عام، لا يتم تفصيل تأكيد صريح لمعالجة بيانات FIDO السابقة من التجار (غير SPC) داخل ACS لتقييم المخاطر في المقتطفات المقدمة.
• دعم SPC (للتحدي): تظهر Worldline مؤشرات واضحة على دعم SPC. تقر وثائقهم بتطور EMV 3DS 2.3 ليشمل SPC/FIDO. يسوقون صراحةً لحلهم "WL Trusted Authentication" على أنه يدعم مصادقة FIDO authentication ويقدمون "WL FIDO Server" مناسبًا لـ "حالات استخدام 3DS، مع emvCO2.3 و SPC.

• التواجد في السوق: تضع GPayments منصة ActiveAccess كـ "منصة خادم تحكم في الوصول (ACS) قوية ورائدة في السوق" مع أكثر من 20 عامًا في مجال 3D Secure space. وهي معتمدة من قبل أنظمة البطاقات الرئيسية (Visa Secure، Mastercard Identity Check، JCB J/Secure) لكل من 3DS1 و EMV 3DS. يمكن نشر حلهم محليًا أو استضافته على السحابة. تحدد تقارير السوق GPayments كلاعب بارز يقدم حلول ACS solutions.
• دعم بيانات FIDO غير SPC (للمسار السلس): يدعم ActiveAccess التكامل مع حلول RBA من جهات خارجية ويستخدم معلمات مختلفة لتقييم المخاطر الخاص به. ومع ذلك، لا تذكر الوثائق المقدمة صراحةً دعم استيعاب أو استخدام بيانات مصادقة FIDO السابقة من التجار (غير SPC) لتقييم المخاطر السلس.
• دعم SPC (للتحدي): لا تذكر الوثائق التي تمت مراجعتها لـ ActiveAccess صراحةً دعم تأكيد الدفع الآمن (SPC)، أو تحديات WebAuthn، أو تحديات FIDO كجزء من قدرات مسار التحدي الخاص بها. بينما يدعمون طرق مصادقة مختلفة بما في ذلك OOB (والتي يمكن أن تشمل القياسات الحيوية)، فإن دعم SPC المحدد غير واضح من المعلومات المتاحة.

• التواجد في السوق: Visa، كشبكة دفع عالمية رئيسية، تحدد برنامج Visa Secure بناءً على معيار EMV 3DS. لقد كانوا روادًا في بروتوكول 3DS الأصلي. بدلاً من العمل بشكل أساسي كمورد مباشر لـ ACS بنفس طريقة شركات التكنولوجيا مثل Entersekt أو Broadcom، تدير Visa البرنامج وتعتمد على قائمة من موردي 3DS المعتمدين (بما في ذلك مزودي ACS) الذين تكون منتجاتهم معتمدة ومتوافقة مع EMV 3DS وقواعد Visa Secure. عادةً ما تشتري الجهات المصدرة حلول ACS من هؤلاء الموردين المعتمدين. تركز Visa نفسها على الشبكة (خادم الدليل)، وتحديد قواعد البرنامج، وتعزيز التبني، ودفع الابتكار مثل المشاريع التجريبية لـ SPC.
• دعم بيانات FIDO غير SPC (للمسار السلس): يدعم Visa Secure، القائم على EMV 3DS، بطبيعته تبادل البيانات الغنية لتقييم المخاطر لتمكين المسار السلس. يعمل إطار عمل EMVCo/FIDO لتمرير بيانات FIDO السابقة داخل نظام Visa Secure البيئي إذا كان مورد ACS المختار يدعم معالجتها it.
• دعم SPC (للتحدي): تشارك Visa بنشاط في تجربة وتعزيز SPC. إنهم يعملون مع شركاء (مثل Netcetera و Modirum/Entersekt في المشاريع التجريبية) لاختبار وتحسين تدفق SPC ضمن بروتوكول 3DS. تشير هذه المشاركة القوية إلى دعم استراتيجي لـ SPC كطريقة تحدي ضمن برنامج Visa Secure، ويتوقف ذلك على جاهزية النظام البيئي (دعم ACS والتاجر والمتصفح support).

• التواجد في السوق: على غرار Visa، تدير Mastercard برنامج Mastercard Identity Check القائم على EMV 3DS. يقدمون خيارات للجهات المصدرة والتجار، بما في ذلك المعالجة الاحتياطية وربما الاستفادة من الشركاء أو الشركات التابعة مثل NuData. استحوذت Mastercard على NuData Security، وهي شركة للقياسات الحيوية السلوكية، في عام 2017، مما عزز قدراتها على تقييم المخاطر. كما يؤكدون على الابتكار المستمر في القياسات الحيوية و RBA والذكاء الاصطناعي. مثل Visa، يعتمدون على موردين معتمدين لمكونات ACS الأساسية ولكن قد يقدمون خدمات مجمعة أو يستفيدون من التكنولوجيا المكتسبة.
• دعم بيانات FIDO غير SPC (للمسار السلس): يستفيد Mastercard Identity Check من تبادل البيانات الغني لـ EMV 3DS 2.x لتحسين اتخاذ قرارات المخاطر والتدفق السلس. يشير استحواذهم على NuData إلى تركيز قوي على التحليلات السلوكية كجزء من تقييم المخاطر هذا. سيعتمد دعم معالجة بيانات FIDO السابقة من التجار على تنفيذ ACS المحدد الذي تستخدمه الجهة المصدرة ضمن برنامج Identity Check.
• دعم SPC (للتحدي): تعد Mastercard عضوًا رئيسيًا في EMVCo وتشارك في تطوير معايير EMV 3DS، بما في ذلك الإصدار 2.3 الذي يدعم SPC. كما أنهم يروجون لتبني مفاتيح المرور بشكل أوسع. يمكن العثور على مزيد من التفاصيل هنا. إنهم داعم قوي لـ SPC ويدفعون نحو طرق المصادقة الحديثة.

يضم سوق EMV 3DS ACS العديد من الموردين بخلاف أولئك المفصلين أعلاه. يقدم موردون مثل /n software و RSA و 2C2P و 3dsecure.io و Adyen و ACI Worldwide و Computop وغيرهم أيضًا حلولًا معتمدة أو يلعبون أدوارًا مهمة في مناطق أو قطاعات محددة. يهدف هذا التحليل إلى تغطية اللاعبين العالميين البارزين ولكنه ليس شاملاً بسبب الطبيعة الديناميكية للسوق. تتطور قدرات الموردين، لا سيما فيما يتعلق بالمعايير الناشئة مثل SPC، بسرعة. إذا لاحظت أي عدم دقة أو لديك معلومات محدثة حول دعم الموردين لبيانات FIDO أو تأكيد الدفع الآمن، فيرجى التواصل معنا لضمان بقاء هذه النظرة العامة حديثة ودقيقة.

المبدأ الأساسي لاستخدام تأكيد الدفع الآمن (SPC) ضمن مسار تحدي EMV 3DS هو أن مصدر البطاقة (أو طرف مفوض صراحة من قبل المصدر، مثل نظام الدفع) يعمل كطرف معتمد (Relying Party) في FIDO (RP). وهذا يختلف جوهريًا عن تدفق بيانات FIDO غير SPC الموصوف سابقًا، حيث يعمل التاجر عادةً كـ RP لأغراض تسجيل الدخول/المصادقة الخاصة به purposes.

لكي يعمل SPC في تحدي 3DS، تشتمل الخطوات التالية:

1. التسجيل: يجب على حامل البطاقة أولاً تسجيل أداة مصادقة FIDO (مثل القياسات الحيوية للجهاز كبصمة الإصبع/معرف الوجه، أو رقم التعريف الشخصي للجهاز، أو مفتاح أمان متنقل) لدى البنك المصدر لبطاقته. تنشئ هذه العملية مفتاح مرور (passkey)، حيث يتم تخزين المفتاح العام ومعرف بيانات اعتماد فريد من قبل الجهة المصدرة وربطه بحساب حامل البطاقة أو بطاقة دفع محددة. قد يحدث التسجيل داخل تطبيق البنك على الهاتف المحمول، أو بوابة الخدمات المصرفية عبر الإنترنت، أو قد يتم عرضه بعد تحدي 3DS تقليدي ناجح. بشكل حاسم، لكي يتم استدعاء SPC من قبل طرف ثالث مثل موقع ويب تاجر، يجب عادةً إنشاء بيانات الاعتماد بموافقة صريحة من المستخدم تسمح باستخدامها في مثل هذه السياقات، وغالبًا ما يتضمن ذلك امتدادات WebAuthn محددة أثناء التسجيل.
2. المصادقة (أثناء تحدي 3DS):
   • عندما تؤدي معاملة 3DS إلى تحدي، وتدعم الجهة المصدرة/ACS وتختار SPC، يحدد ACS معرف (معرفات) بيانات اعتماد FIDO ذات الصلة المرتبطة بحامل البطاقة والجهاز.
   • يدرج ACS معرف (معرفات) بيانات الاعتماد هذه، جنبًا إلى جنب مع تحدي تشفيري فريد وتفاصيل المعاملة (المبلغ، العملة، اسم/أصل المستفيد، رمز/اسم عرض الأداة)، في استجابة المصادقة (ARes) المرسلة مرة أخرى إلى خادم 3DS/الطالب.
   • يستخدم مكون طالب 3DS لدى التاجر هذه المعلومات من ARes لاستدعاء واجهة برمجة تطبيقات SPC في المتصفح.
   • يعرض المتصفح مربع حوار موحد وآمن يعرض تفاصيل المعاملة التي قدمها ACS.
   • يؤكد المستخدم المعاملة ويصادق باستخدام أداة مصادقة FIDO المسجلة لديه (على سبيل المثال، لمس مستشعر بصمات الأصابع، التعرف على الوجه، إدخال رقم التعريف الشخصي للجهاز، النقر على مفتاح أمان). يفتح هذا الإجراء المفتاح الخاص المخزن بشكل آمن على الجهاز/أداة المصادقة.
   • توقع أداة المصادقة على تفاصيل المعاملة المعروضة والتحدي التشفيري المستلم من ACS.
   • يعيد المتصفح تأكيد FIDO الناتج (حمولة البيانات الموقعة) إلى طالب 3DS لدى التاجر.
   • يرسل طالب 3DS هذا التأكيد مرة أخرى إلى Issuer ACS، وعادة ما يكون مغلفًا داخل رسالة AReq ثانية.
   • يستخدم Issuer/ACS، بصفته الطرف المعتمد الرسمي، المفتاح العام المخزن مسبقًا لحامل البطاقة للتحقق تشفيريًا من التوقيع على التأكيد. يؤكد التحقق الناجح أن حامل البطاقة الشرعي، باستخدام أداة المصادقة المسجلة لديه، وافق على تفاصيل المعاملة المحددة المعروضة.

يستلزم دمج SPC في تدفق تحدي EMV 3DS تعديلات على تسلسل الرسائل القياسي، والذي يتضمن عادةً تبادلين لـ AReq/ARes:

1. طلب المصادقة الأولي (AReq #1): يبدأ التاجر/خادم 3DS عملية 3DS عن طريق إرسال AReq يحتوي على بيانات المعاملة والجهاز. للإشارة إلى القدرة على SPC، قد يتضمن الطلب مؤشرًا مثل threeDSRequestorSpcSupport مضبوطًا على 'Y' (أو ما شابه، اعتمادًا على تنفيذ مورد ACS).
2. استجابة المصادقة الأولية (ARes #1): إذا قرر ACS أن التحدي مطلوب واختار SPC، فإنه يستجيب بـ ARes يشير إلى ذلك. قد يتم تعيين transStatus على 'S' (يشير إلى أن SPC مطلوب) أو قيمة محددة أخرى. يحتوي هذا ARes على حمولة البيانات اللازمة لاستدعاء واجهة برمجة تطبيقات SPC.
3. استدعاء واجهة برمجة تطبيقات SPC ومصادقة FIDO: يتلقى مكون طالب 3DS لدى التاجر ARes #1 ويستخدم الحمولة لاستدعاء واجهة برمجة تطبيقات SPC في المتصفح. يتفاعل المستخدم مع أداة المصادقة الخاصة به عبر واجهة المستخدم الآمنة للمتصفح.
4. إرجاع تأكيد FIDO: عند نجاح مصادقة المستخدم، يعيد المتصفح بيانات تأكيد FIDO إلى طالب 3DS.
5. طلب المصادقة الثاني (AReq #2): يقوم طالب 3DS بإنشاء وإرسال رسالة AReq ثانية إلى ACS. الغرض الأساسي من هذه الرسالة هو نقل بيانات تأكيد FIDO. تتضمن عادةً:
   • ReqAuthData: تحتوي على تأكيد FIDO.
   • ReqAuthMethod: مضبوط على '09' (أو القيمة المخصصة لتأكيد SPC/FIDO).
   • من المحتمل قيمة AuthenticationInformation من ARes #1 لربط الطلبات.
   • اختياريًا، SPCIncompletionIndicator إذا فشل استدعاء واجهة برمجة تطبيقات SPC أو انتهت مهلته.
6. استجابة المصادقة النهائية (ARes #2): يتلقى ACS AReq #2، ويتحقق من صحة تأكيد FIDO باستخدام المفتاح العام لحامل البطاقة، ويحدد نتيجة المصادقة النهائية. يرسل مرة أخرى ARes #2 يحتوي على حالة المعاملة النهائية (على سبيل المثال، transStatus = 'Y' للمصادقة الناجحة، 'N' للفشل).

يمثل هذا التدفق المكون من رسالتي AReq انحرافًا عن طرق تحدي 3DS التقليدية (مثل OTP أو OOB التي يتم التعامل معها عبر رسائل CReq/CRes أو RReq/RRes) والتي تكتمل عادةً ضمن دورة AReq/ARes الأولية بعد استلام transStatus = 'C'. في حين أن جزء تفاعل المستخدم في SPC (مسح بيومتري، إدخال رقم التعريف الشخصي) غالبًا ما يكون أسرع بكثير من كتابة OTP، فإن إدخال جولة كاملة ثانية من AReq/ARes يضيف زمن انتقال الشبكة بين خادم 3DS وخادم الدليل و ACS. يجب على المنفذين والموردين تحسين هذا التدفق بعناية والتعامل مع المهلات المحتملة لضمان بقاء وقت المعاملة الإجمالي من طرف إلى طرف تنافسيًا ويلبي توقعات المستخدم.

تم وضع تأكيد الدفع الآمن للتبني العالمي نظرًا لتوحيده المزدوج. يتم تعريفه رسميًا كمعيار ويب من قبل اتحاد شبكة الويب العالمية (W3C)، بعد أن وصل إلى حالة توصية مرشحة في منتصف عام 2023 مع استمرار العمل ليصبح توصية كاملة. في الوقت نفسه، تم دمج SPC في مواصفات EMV® 3-D Secure بدءًا من الإصدار 2.3، الذي تديره EMVCo، الهيئة الفنية العالمية لمعايير الدفع. يضمن هذا التكامل أن يعمل SPC ضمن الإطار العالمي المعمول به لمصادقة معاملات CNP. يؤكد التعاون بين W3C وتحالف FIDO و EMVCo على الجهد المبذول على مستوى الصناعة لإنشاء معايير قابلة للتشغيل البيني للمدفوعات عبر الإنترنت الآمنة وسهلة الاستخدام.

بينما يساعد تصميم SPC، وخاصة قدرته على ربط مصادقة المستخدم تشفيريًا بتفاصيل معاملة محددة ("الربط الديناميكي")، في تلبية متطلبات المصادقة القوية للعملاء (SCA) بموجب لوائح مثل توجيه خدمات الدفع في أوروبا (PSD2)، فإن فائدته لا تقتصر على هذه المناطق المفروضة. يعد SPC معيارًا تقنيًا عالميًا قابلاً للتطبيق في أي سوق، بما في ذلك الولايات المتحدة وكندا، شريطة وجود مكونات النظام البيئي اللازمة في مكانها.

في الأسواق التي لا توجد بها تفويضات SCA صريحة لكل معاملة، فإن الدوافع الأساسية لتبني SPC هي:

• تحسين تجربة المستخدم: تقديم طريقة تحدي قد تكون أسرع وأكثر ملاءمة (على سبيل المثال، باستخدام القياسات الحيوية للجهاز) مقارنة بـ OTPs التقليدية أو الأسئلة القائمة على المعرفة، مما قد يقلل من التخلي عن عربة التسوق. أظهرت المشاريع التجريبية انخفاضًا كبيرًا في وقت المصادقة مقارنة بالتحديات التقليدية.
• تعزيز الأمان: المصادقة القائمة على FIDO المتأصلة في SPC مقاومة لهجمات التصيد الاحتيالي وحشو بيانات الاعتماد والتهديدات الشائعة الأخرى التي تستهدف كلمات المرور و OTPs.

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

يعتمد النشر الناجح والتبني الواسع النطاق لتأكيد الدفع الآمن (SPC) بشكل كبير على الجاهزية المنسقة عبر مكونات متعددة في النظام البيئي للمدفوعات. بينما تنضج معايير FIDO الأساسية وتقنية مفاتيح المرور بسرعة، يظل الدعم المحدد على مستوى المتصفح لواجهة برمجة تطبيقات SPC والتكامل الكامل عبر سلسلة الدفع عقبات حاسمة. يتقدم اللاعبون الآخرون في النظام البيئي بشكل جيد بشكل عام.

ملخص جاهزية النظام البيئي (الحالة في مايو 2025)

ماذا يعني هذا عمليًا (مايو 2025)

العامل المحدد الرئيسي لتبني SPC هو طبقة وكيل المستخدم (المتصفح):

• Safari (macOS و iOS): ❌ لا يزال WebKit يفتقر إلى طريقة طلب الدفع secure-payment-confirmation. يجب على أي موقع يتم زيارته في Safari الرجوع إلى طرق مصادقة أخرى (OTP، OOB، ربما تجارب WebAuthn غير SPC). لم تعرب Apple عن اهتمامها بتنفيذ الامتداد.
• Chrome / Edge (Chromium): ⚠️ الإصدار الأساسي من SPC (إنشاء بيانات الاعتماد + المصادقة) مستقر، ولكن المفاتيح لم يتم تخزينها بعد في أدوات المصادقة للأجهزة ولم تستخدم إلا في المشاريع التجريبية. يجب على المنفذين توقع تغييرات قد تكسر التوافق والاستعداد لتقييد الوظائف بناءً على فحوصات توفر واجهة برمجة التطبيقات (على سبيل المثال، canMakePayment()) أو علامات الميزات.
• Firefox: ❌ أشار الفريق إلى اهتمامه ولكن ليس لديه جدول زمني للتنفيذ ملتزم به؛ يجب على التجار التخطيط لمسارات تراجع سلسة.

نظرًا لأن البنية التحتية للجهة المصدرة (ACS، خوادم FIDO) وخوادم دليل الأنظمة جاهزة إلى حد كبير أو تتقدم بسرعة، وأدوات التاجر/PSP أصبحت متاحة، فإن العائق الرئيسي أمام الاستخدام الواسع النطاق لـ SPC هو دعم المتصفح. بمجرد تحسن تغطية المتصفح، تتضمن المهام المتبقية بشكل أساسي تكامل التاجر/PSP (الترقية إلى EMV 3DS v2.3+، إضافة منطق استدعاء SPC، التعامل مع تدفق AReq المزدوج) وتوسيع نطاق تسجيل الجهات المصدرة لمفاتيح المرور خصيصًا لسياقات الدفع.

في الوقت الحالي، توقع ظهور SPC فقط لشريحة محدودة من المعاملات. حتى يقوم Safari (وبالتالي النظام البيئي iOS بأكمله) بشحن الدعم، لا يمكن لـ SPC تحقيق دعم السوق.

يكشف التحليل عن تباين واضح في جاهزية تكاملي FIDO الرئيسيين ضمن EMV 3DS اعتبارًا من مايو 2025. بينما تتقدم العناصر الأساسية لـ تأكيد الدفع الآمن (SPC) كطريقة تحدي - لا سيما قدرات الجهة المصدرة/ACS وجاهزية الأنظمة - فإن تبنيه على نطاق واسع يعوقه بشكل كبير العائق الحاسم المتمثل في دعم المتصفح، وأبرزها عدم التنفيذ في Safari من Apple (مما يحظر جميع أجهزة iOS/iPadOS) و Firefox، إلى جانب القيود في تطبيقات Chromium الحالية. يظل SPC حالة مستقبلية واعدة، لكنه ليس حلاً عمليًا وشاملاً اليوم.

بناءً على حالة النظام البيئي الحالية، نوصي بما يلي:

• التجار:
  • إعطاء الأولوية لتبني Passkeys: قم بتنفيذ مفاتيح المرور لتسجيل دخول المستخدم والمصادقة. بالإضافة إلى تحسين الأمان وتجربة المستخدم الخاصة بك (عوامل لم يتم تفصيلها هنا)، فإن هذا ينشئ البيانات اللازمة لتدفقات 3DS السلسة.
  • تمرير بيانات FIDO: تأكد من أن تكامل 3DS الخاص بك يملأ بشكل صحيح حقل threeDSRequestorAuthenticationInfo بتفاصيل مصادقات مفاتيح المرور السابقة الناجحة أثناء جلسة الدفع. اعمل مع مزود PSP/3DS الخاص بك لتمكين ذلك.
• الجهات المصدرة:
  • تسجيل Passkeys للمستخدمين: ابدأ في عرض وتشجيع حاملي البطاقات على تسجيل مفاتيح المرور مباشرة معك (للوصول إلى تطبيق البنك، و SPC المستقبلي، وما إلى ذلك). قم ببناء البنية التحتية اللازمة لـ FIDO Relying Party.
  • الاستفادة من بيانات Passkey الخاصة بالتجار الآن: اطلب من مورد ACS الخاص بك استيعاب واستخدام بيانات FIDO التي يمررها التجار (threeDSRequestorAuthenticationInfo) كإشارة إيجابية قوية ضمن محرك RBA الخاص بك. احتفظ بسجلات لمفاتيح مرور التجار الموثوقة المرتبطة بالمستخدمين حيثما أمكن ذلك. استهدف زيادة الموافقات السلسة بشكل كبير للمعاملات التي تسبقها مصادقة قوية بمفتاح مرور التاجر.
  • الاستعداد لـ SPC، والمراقبة بنشاط: تأكد من أن خارطة طريق ACS الخاصة بك تتضمن دعمًا كاملاً لـ EMV 3DS v2.3.1+ SPC، ولكن تعامل معها على أنها تحسين مستقبلي. راقب باستمرار تطورات المتصفح (خاصة Safari) لتقييم متى قد يصبح SPC قابلاً للتطبيق على نطاق واسع.
• موردو ACS:
  • تعزيز RBA بذكاء Passkey: استثمر بكثافة في قدرة محرك RBA الخاص بك على معالجة بيانات FIDO/passkey التي يقدمها التجار والثقة بها. قم بتطوير منطق لتتبع استخدام مفاتيح المرور عبر مشتريات التجار لمستخدم/جهاز معين. قم بتخزين المفاتيح العامة (من تسجيل الجهة المصدرة المباشر) للتحقق من السلامة التشفيرية لبيانات مصادقة التاجر إذا تم توفيرها. اربط استخدام مفاتيح المرور الناجح مباشرة بمعدلات موافقة سلسة أعلى.
  • بناء قدرات SPC قوية: استمر في تطوير واعتماد دعم تدفق تحدي SPC الكامل (EMV 3DS v2.3.1+) استعدادًا لتبني السوق في المستقبل.
• أنظمة/شبكات الدفع:
  • دعم بيانات FIDO للمسار السلس: قم بالترويج بنشاط وربما تحفيز تمرير واستخدام بيانات مصادقة FIDO الخاصة بالتجار (threeDSRequestorAuthenticationInfo) ضمن تدفق 3DS. قدم إرشادات ودعمًا واضحين للجهات المصدرة وموردي ACS حول الاستفادة من هذه البيانات بفعالية لـ RBA.
  • مواصلة الدعوة لـ SPC والتواصل مع المتصفحات: حافظ على الجهود لتوحيد وتعزيز SPC، والتواصل بشكل حاسم مع موردي المتصفحات (Apple، Mozilla، Google) لتشجيع التنفيذ الكامل والقابل للتشغيل البيني لمعيار واجهة برمجة تطبيقات SPC.

تكمن الفرصة الفورية والملموسة في تعزيز المسار السلس من خلال الاستفادة من التبني المتزايد لمفاتيح المرور على مستوى التجار. يجب على جميع المشاركين في النظام البيئي إعطاء الأولوية لتمكين إنشاء ونقل واستهلاك ذكي لبيانات المصادقة السابقة هذه ضمن إطار EMV 3DS الحالي. يوفر هذا المسار فوائد قصيرة الأجل في تقليل الاحتكاك وربما الاحتيال دون انتظار دعم متصفح SPC العالمي. بالتزامن مع ذلك، فإن إعداد الأساس لـ SPC - لا سيما تسجيل مفاتيح المرور لدى الجهة المصدرة وجاهزية ACS - يضمن أن يكون النظام البيئي في وضع يسمح له بتبني طريقة التحدي المتفوقة هذه بمجرد حل عنق الزجاجة في المتصفح.