الربط الديناميكي باستخدام Passkeys: تأكيد الدفع الآمن (SPC)

Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.

Get Report

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

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

وفقًا لتوجيه PSD2 والمعايير الفنية التنظيمية المصاحبة له، يُعرَّف الربط الديناميكي بأنه عملية تضمن أن "رمز المصادقة الذي يتم إنشاؤه خاص بالمبلغ والمستفيد الذي وافق عليهما الدافع عند بدء معاملة الدفع الإلكترونية" (المادة 97(2) من PSD2). هذا يعني أن أي تغييرات في تفاصيل الدفع ستؤدي إلى إبطال رمز المصادقة، مما يتطلب إعادة المصادقة.

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

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

Subscribe to our Passkeys Substack for the latest news.

Subscribe

تتوسع المادة 5 من المعايير الفنية التنظيمية (RTS) في متطلبات رمز المصادقة في الربط الديناميكي. تشمل هذه المتطلبات:

• وعي الدافع: يتم إعلام الدافع بمبلغ معاملة الدفع وبالمستفيد.

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

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

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

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

تثق الشركات في Corbado لحماية مستخدميها وجعل عمليات تسجيل الدخول أكثر سلاسة باستخدام Passkeys. احصل على استشارتك المجانية حول Passkeys الآن.

احصل على استشارة مجانية

دعنا أولاً نحلل الخيارات المختلفة لكيفية استخدام Passkeys في الربط الديناميكي.

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

Become part of our Passkeys Community for updates & support.

Join

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

دعنا نحلل قيود وتحديات هذين الخيارين.

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

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

هذه المشكلة ليست فريدة من نوعها لـ Passkeys؛ إنها تحدٍ شائع عبر أنظمة الدفع المختلفة عبر الإنترنت. إن ضمان أن يكون الدافع على دراية كاملة ويوافق على جميع تفاصيل المعاملة قبل بدء الدفع أمر حاسم للحفاظ على الثقة والأمان.

القيود الأكثر أهمية لدمج Passkeys في الربط الديناميكي تنشأ في التمييز بين التسجيل للطرف الأول والطرف الثالث.

ما هو سياق الدفع للطرف الأول؟

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

يرجى الاطلاع على منشور مدونتنا حول تنفيذ Mastercard لـ Passkeys في سياق الدفع للطرف الأول.

ما هو سياق الدفع للطرف الثالث؟

في سياق الدفع للطرف الثالث، يكون المستخدم على صفحة تاجر في عملية الدفع على نطاق مختلف (مثل amazon.com) ويريد بدء معاملة ببطاقة الائتمان:

• ✔️ الحالة 1 – يمتلك المستخدم بالفعل مفتاح مرور من جهة الإصدار / البنك: يعرض التاجر iframe حيث يمكن أن تتم المصادقة باستخدام مفتاح المرور. يتم عرض IFRAME بواسطة عملية 3-D Secure 2 (3DSS/EMV 3DS) الأساسية الموجودة بالفعل لمعاملات بطاقات الائتمان التي تحتاج إلى دعم SCA والربط الديناميكي.

• ❌ الحالة 2 – لا يمتلك المستخدم مفتاح مرور من جهة الإصدار / البنك: مرة أخرى، يعرض التاجر iframe. نظرًا لعدم توفر Passkeys بعد، يتم مصادقة المستخدم بواسطة عوامل المصادقة الحالية (مثل كلمة المرور لمرة واحدة عبر الرسائل القصيرة أو تطبيق الخدمات المصرفية الأصلي على هاتفه الذكي). في هذه المرحلة، بعد المصادقة الناجحة، ستكون اللحظة المثالية لتسجيل مفتاح مرور للمستخدم، ولكن هذا غير مسموح به بسبب قيود معيار WebAuthn. لا يُسمح بتسجيل Passkeys في iframe عبر المصادر (يجب أن يكون نطاق الصفحة الرئيسية و iframe متطابقين). سيكون التسجيل التدريجي كما في لقطة الشاشة التالية مستحيلاً:

هل سيتم دعم تسجيل Passkeys في iframes عبر المصادر في المستقبل؟

بينما توفر Passkeys حلاً جيدًا للربط الديناميكي في سياق الدفع للطرف الأول داخل نطاق واحد، في سياقات الدفع للطرف الثالث، لا يدعمها حاليًا WebAuthn Level 2. ومع ذلك، فإن الخبر السار هو أن دعم iframe عبر المصادر مدمج بالفعل في مواصفات WebAuthn Level 3 الجارية (والتي ستتاح بشكل عام بحلول نهاية عام 2024). ومع ذلك، لا يزال يتعين على المتصفحات مواكبة المواصفات:

حتى اليوم، يبدو أنه بحلول عام 2024، يمكن أن يصبح تغطية تسجيل Passkeys عبر المصادر حقيقة واقعة في المتصفحات الرئيسية، مما يرفع أهم القيود الفنية في استخدام Passkeys للمدفوعات.

كانت هناك عدة محاولات (مثل BasicCard، PaymentHandler أو PaymentManifest) من قبل مجموعات العمل التي بدأتها Google في W3C لتحسين تجربة الدفع على الويب. حتى الآن لم يكتسب أي منها تغطية سوقية واستخدامًا كبيرًا. لا يزال الاحتكاك في عملية الدفع لمعاملات التجارة الإلكترونية يمثل تحديًا كبيرًا مع زيادة التنظيم ضد الاحتيال. يعد معيار تأكيد الدفع الآمن (Secure Payment Confirmation) الذي بدأته Google و Stripe حاليًا المعيار الواعد الذي يبني على معيار WebAuthn.

يعالج تأكيد الدفع الآمن (SPC) جميع العناصر المهمة في SCA الخاص بـ PSD2 بما في ذلك متطلب الربط الديناميكي، وفي نفس الوقت يحاول تحسين تجربة المستخدم.

• تقديم تجربة مستخدم أصلية للمتصفح: يستفيد SPC من المتصفح لتوفير تجربة مصادقة متسقة ومبسطة عبر مواقع التجار والأطراف المعتمدة المختلفة. يهدف هذا النهج إلى تعزيز أمان المعاملات بما يتجاوز ما يتم تحقيقه عادةً مع المحتوى المعروض في iframe من خلال وجود مظهر متسق وضمان وعي الدافع:

مثال من https://www.w3.org/press-releases/2023/spc-cr/

• توفير دليل تشفيري: يضمن المعيار إنشاء دليل تشفيري لتأكيد المستخدم لتفاصيل الدفع وتضمينه في إثبات WebAuthn دون الحاجة إلى ترميز المعلومات في تحدي WebAuthn.

• السماح بالتسجيل من طرف ثالث: على عكس معيار WebAuthn Level 2، حيث يجب أن يحدث تسجيل أداة المصادقة في سياق الطرف الأول، يتيح SPC تسجيل Passkeys مباشرة من iframe عبر المصادر. تعالج هذه الإمكانية حالات الاستخدام الشائعة في نظام الدفع وتسهل التكامل للتجار ومعالجي الدفع. كما ناقشنا أعلاه، هذه الوظيفة هي بالفعل جزء من الإصدار التالي من المعيار الأساسي وبالتالي من المحتمل أن تتم إزالتها في المستقبل من SPC.

• المصادقة عبر المصادر للمدفوعات: يوسع SPC فائدة WebAuthn من خلال السماح لأي مصدر بإنشاء إثبات لمعاملة، حتى لو كان يستفيد من بيانات اعتماد من طرف معتمد آخر (دون الحاجة إلى مغادرة الصفحة). في هذه الحالة، لا يلزم حتى وجود iframe من التاجر / جهة الإصدار. هذه الميزة مفيدة بشكل خاص في السيناريوهات التي تشارك فيها أطراف متعددة (التاجر + جهة الإصدار / البنك) في عملية المصادقة ويمكن بعد ذلك نقل الإثبات إلى الطرف المعتمد الأصلي (مزود الحساب مثل البنك) للتحقق.

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

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

دعنا نمر على جميع التدفقات الممكنة التي سيسمح بها SPC ونقارنها بـ Passkeys القياسية، حتى نفهم الفوائد.

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

إليك مثال نموذجي لتسجيل SPC Passkey مباشرة على صفحة Mastercard. كما ترى هنا، يتم عرض إنشاء مفتاح المرور مباشرة بعد إتمام المصادقة عبر كلمة المرور لمرة واحدة عبر الرسائل القصيرة في هذه الحالة.

في هذه الحالة، سيبدو الاتصال كعملية تسجيل Passkeys قياسية حيث يحدث هذا بالكامل في سياق الطرف الأول.

مأخوذ من https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

يمكن الآن استخدام SPC Passkey هذا على موقع تاجر للمصادقة، في iframe على موقع التاجر وللمصادقة عبر المصادر (انظر أدناه).

كما ناقشنا من قبل، فإن عملية تسجيل SPC Passkey على موقع تاجر ستحدث عادةً أثناء معاملة الدفع، ضمن سياق تدفق 3-D Secure (3DS). تم تصميم هذا التدفق لتعزيز أمان معاملات بطاقات الائتمان والخصم عبر الإنترنت من خلال إشراك خطوة مصادقة إضافية تتحقق من هوية حامل البطاقة.

أثناء معاملة الدفع، عند بدء تدفق 3DS، يتم تسهيل عملية المصادقة من خلال iframe مستضاف على موقع التاجر (مثل amazon.com) ولكن يتم التحكم فيه بواسطة مزود خدمة الدفع أو البنك المصدر (مثل mastercard.com). يعمل هذا iframe كبيئة آمنة للعميل لمصادقة هويته باستخدام عوامل المصادقة الحالية.

بمجرد أن يصادق العميل على نفسه بنجاح باستخدام هذه العوامل التقليدية (مثل كلمة المرور لمرة واحدة عبر الرسائل القصيرة أو تطبيق الخدمات المصرفية)، هناك فرصة لتسجيل SPC Passkey للمعاملات المستقبلية. نظرًا لأن معيار SPC يسمح بإنشاء Passkey عبر المصادر من داخل iframes، فإن هذا سيعمل. سيتضمن تسجيل مفتاح المرور هذا في iframe عادةً قيام العميل بإجراء يولد ويربط مفتاح المرور ببطاقته الائتمانية، مثل التحقق من بصمة إصبعه أو التعرف على الوجه على جهاز متوافق. ضع في اعتبارك أن iframe يتم التحكم فيه بواسطة مزود خدمة الدفع (مثل PayPal) أو البنك المصدر (مثل mastercard.com). لذلك، يتم إنشاء SPC Passkey مع جهة الإصدار / البنك مباشرة وليس التاجر. سيبدو التدفق المبسط كما يلي:

مأخوذ من https://developer.chrome.com/docs/payments/register-secure-payment-confirmation

على https://spc-merchant.glitch.me/، أنشأت Google تطبيقًا تجريبيًا يمكن الوصول إليه عبر Chrome على Windows و Mac، والذي يوضح كيف سيعمل هذا من داخل iframe:

يسمح أيضًا باللعب بموقع البنك مباشرة والذي يتم استضافته تحت: https://spc-rp.glitch.me/reauth. في هذا المثال، لا يلزم وجود اتصال خارج النطاق مع واجهات برمجة التطبيقات بين التاجر وجهة الإصدار / البنك - يتم التعامل مع كل شيء بواسطة المتصفح. ستعمل المصادقة باستخدام مفتاح مرور موجود بنفس الطريقة من داخل iframe.

في المثال التالي، نرى المصادقة عبر المصادر حيث قام المستخدم بالفعل بتسجيل SPC Passkey مع Mastercard. يمكن لموقع التاجر المثال (decorshop.com) تشغيل المصادقة عبر المصادر. الفرق الرئيسي والمهم هو أن صفحة التاجر / جهة الإصدار لا تكون مرئية أبدًا أثناء عملية المصادقة. يعرض المتصفح بالاشتراك مع نظام التشغيل تجربة الدفع المحددة مسبقًا (التي يوفرها تنفيذ المتصفح لمعيار SPC) ونافذة المصادقة (معيار WebAuthn). يتم التعامل مع الاتصال بين التاجر وجهة الإصدار / البنك في الخلفية.

الأصل من (معدل جزئيًا): https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf (Mastercard)

الأصل من (معدل جزئيًا): https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams

عند استخدام المصادقة عبر المصادر، يتواصل التاجر مع جهة الإصدار / البنك عبر شكل من أشكال واجهة برمجة التطبيقات لتبادل المعلومات حول بيانات الاعتماد الحالية (رقم 2 في مخطط التسلسل أعلاه). إذا كانت بيانات الاعتماد موجودة وكان متصفح المستخدم يدعم SPC، تبدأ المصادقة. في النهاية، يتم إرجاع الإثبات على طول الطريق إلى جهة الإصدار / البنك عبر البروتوكولات الحالية مثل EMV 3DS، حيث يمكن التحقق من الإثبات تشفيريًا في النهاية (رقم 16).

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

يعد معيار تأكيد الدفع الآمن (SPC) تطورًا مثيرًا للاهتمام في عالم مصادقة الدفع عبر الإنترنت، ويهدف إلى تعزيز الأمان مع تبسيط تجربة المستخدم. حتى اليوم، يعد Google Chrome المتصفح الرئيسي الوحيد الذي يدعم SPC بشكل ما. ومع ذلك، هذا ليس مفاجئًا لأن المعيار قد بدأ جزئيًا من قبل Google. من المتصفحات الرئيسية الأخرى مثل Safari من Apple و Mozilla Firefox، هناك نقص ملحوظ في الالتزام مع عدم وجود إشارات واضحة حول خططهم لدعم SPC. على وجه التحديد، تدفع Apple معيارها الخاص Apple Pay ولا يبدو أنها مهتمة بمعايير الدفع الأخرى.

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

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

التحديات الموضحة أعلاه، خاصة حول وعي الدافع، دفعت إلى عمل مستمر في مجموعة عمل WebAuthn على ما يسمى بملحق التأكيد (المعروف سابقًا باسم “txAuthSimple”) ضمن معيار WebAuthN. يهدف إلى السماح إما لأداة المصادقة أو المتصفح/نظام التشغيل (في واجهة مستخدم مميزة) بعرض تفاصيل المعاملة للمستخدم وضمان أن الطرف المعتمد يتلقى دليلاً تشفيريًا على أن المستخدم قد أكد بالفعل هذه التفاصيل. يعالج هذا بشكل مباشر مشكلة "نقص وعي المستخدم المضمون" الموصوفة في القسم 3.3.1.

على غرار كيفية توفير تأكيد الدفع الآمن (SPC) لمربع حوار مخصص يحركه المتصفح، يعالج ملحق التأكيد مشكلة "ما تراه هو ما توقعه" (WYSIWYS). أهدافه الرئيسية هي:

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

يضيف الملحق حقلاً جديدًا إلى هياكل ملحقات WebAuthn الحالية. توفر الأطراف المعتمدة سلسلة نصية بسيطة (مع تنسيق أساسي اختياري) تسمى confirmation:

partial dictionary AuthenticationExtensionsClientInputs {
  USVString confirmation;
};

عندما يتلقى العميل (المتصفح) هذا، فإنه:

1. يطالب المستخدم بمربع حوار تأكيد خاص (حتى يعرفوا أن هذا أكثر من مجرد تسجيل دخول أساسي).
2. يمرر نفس السلسلة إلى أداة المصادقة كبيانات CBOR إذا كانت أداة المصادقة تدعم الملحق.
3. يعيد أي مخرجات من أداة المصادقة إلى الطرف المعتمد.

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

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

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

• أي عدم تطابق أو تعديل لتفاصيل المعاملة بعد العرض يبطل التوقيع.
• يمكن للطرف المعتمد إثبات أنه تم إعطاء المستخدم تفاصيل المعاملة الصحيحة في وقت التوقيع، مما يفي بمتطلب "وعي الدافع" في PSD2 بشكل أكثر قوة من مجرد تجزئة البيانات في التحدي.

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

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

لمزيد من التفاصيل الفنية، يمكنك إلقاء نظرة على المناقشة الجارية: طلب سحب GitHub #2020. باختصار، يمكن لملحق التأكيد أيضًا سد الفجوة الرئيسية الأخيرة في التدفقات القياسية القائمة على Passkey: توفير دليل تشفيري على ماذا رآه المستخدم بالضبط عندما أعطى موافقته، وإن كان أقل تنظيمًا من تأكيد الدفع الآمن. إذا اكتسب زخمًا بين المتصفحات وبائعي أدوات المصادقة، فقد يصبح طريقة موحدة للغاية لتقديم ضمان أمان WYSIWYS اللازم بموجب الربط الديناميكي لـ PSD2 - وما بعده.

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

في جوهره، يحاول SPC تقديم حل دفع شامل ويتضمن أيضًا الربط الديناميكي كجزء من تدفقه. وفي الوقت نفسه، يعالج ملحق التأكيد متطلب "ما تراه هو ما توقعه" ضمن رسائل WebAuthn القياسية دون فرض تدفق دفع كامل. يمكن لأي من النهجين تسهيل الامتثال لـ PSD2، لكن كل منهما يعتمد على دعم المتصفح و أداة المصادقة لتقديم فوائد حقيقية.

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

• ✔️ Passkeys للمدفوعات التي تبدأ على موقع جهة الإصدار / البنك: تعد Passkeys حلاً جيدًا جدًا لجهات الإصدار / البنوك لتنفيذ الربط الديناميكي في مواقعها وتطبيقاتها مباشرة. يمكن دمجها مع خيارات مصادقة أخرى مثل الإشعارات الفورية أو كلمة المرور لمرة واحدة عبر البريد الإلكتروني / الرسائل القصيرة أو TOTP لتعزيز الأمان بشكل أكبر للمدفوعات عالية المخاطر. بالطبع، يجب أن تكون الاعتبارات المتعلقة بالامتثال لـ SCA دائمًا جزءًا من هذه المناقشة (انظر أيضًا سلسلتنا المكونة من 4 أجزاء حول Passkeys و SCA).

  يمكن تنفيذ حل مقترح من قبل جهات الإصدار / البنوك بأنفسهم حيث أن Passkeys تعتمد على معيار WebAuthn المفتوح. ومع ذلك، يتطلب هذا معرفة فنية كبيرة، والتعامل مع الحالات الخاصة ومواكبة جميع اللوائح والتطورات الفنية الجديدة باستمرار. البديل هو استخدام مزود مصادقة من طرف ثالث. على سبيل المثال، يدعم Corbado Connect الربط الديناميكي عبر توقيع المعاملات، مستفيدًا من تحديات WebAuthn المعدلة. يتم تسجيل جميع المعلومات في سجل التدقيق. هذا ليس مفيدًا فقط للمؤسسات المالية ولكن يمكن الاستفادة منه لجميع أنواع التوقيعات (مثل توقيع المستندات، إجراءات المستخدم عالية المخاطر). اختياريًا، يمكن استخدام كلمة مرور إضافية لمرة واحدة عبر الرسائل القصيرة أو البريد الإلكتروني لتحسين الأمان أكثر.

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

• ❌ SPC Passkeys أو ملحق التأكيد للربط الديناميكي: لم يصل معيار SPC بعد إلى حالة ناضجة ودعم لاستخدامه في بيئات الإنتاج.

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

لماذا تعتبر Passkeys مهمة؟

Passkeys للشركات

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

Download free whitepaper

Work email *

Name *

Company *

Job title *

Phone number

Get whitepaper

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

ومع ذلك، فإن تقدم وقبول أوسع لمعيار SPC أو ملحق التأكيد يعتمد بشكل كبير على اعتماده من قبل المتصفحات الرئيسية - وهي عملية كانت بطيئة، حيث يعد Google Chrome حاليًا الداعم الوحيد. يمكن أن يعيق معدل التبني البطيء هذا بشكل خاص SPC من تجاوز حالته الحالية ما لم تبدأ المزيد من المتصفحات في دمجه. يشير التطوير المستمر والزخم المتزايد لـ Passkeys إلى اتجاه واعد حيث ستلعب الأنظمة التي تعتمد على وحدات أمان الأجهزة (HSMs) مثل الجيوب الآمنة و TEEs و TPMs أيضًا دورًا مهمًا لتطبيقات الدفع حيث توفر هذه التقنيات أمانًا معززًا يمكن أن يجعل الربط الديناميكي للمدفوعات أكثر عملية وراحة ليس فقط للمعاملات التي تبدأ على مواقع الخدمات المصرفية ولكن أيضًا على منصات التجار من الأطراف الثالثة.

تسلط إمكانية توسيع Passkeys لفائدتها لتشمل عمليات الدفع عبر الإنترنت الضوء على جانب مهم في تأمين المعاملات المستندة إلى الويب وجعل الإنترنت بشكل عام مكانًا أكثر أمانًا.