بيانات الاعتماد الرقمية ومفاتيح المرور: أوجه التشابه والاختلاف

• 🔑 مفاتيح المرور (Passkeys): لتسجيل الدخول الآمن. تثبت من أنت (المصادقة) وتحارب التصيد الاحتيالي (phishing) بفعالية.
• 📄 بيانات الاعتماد الرقمية: للإثبات القابل للتحقق. تثبت حقائق عنك (الإشهاد، مثل هويتك ومهاراتك)، وأنت تتحكم بما تتم مشاركته.
• 🤝 أوجه التشابه: كلاهما يستخدم تشفيرًا قويًا لتحسين الأمان وتجربة المستخدم مقارنة بكلمات المرور.
• 🎯 أوجه الاختلاف: تُستخدم مفاتيح المرور بشكل أساسي للوصول إلى الخدمات. بينما تُستخدم بيانات الاعتماد الرقمية لتقديم معلومات موثقة عنك.

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

شهدت مفاتيح المرور قفزة كبيرة في الاستخدام خلال 2023-2025، بفضل الدعم القوي من الشركات الكبرى مثل Apple وGoogle وMicrosoft، بالإضافة إلى تحالف FIDO. استنادًا إلى معيار W3C WebAuthn القوي، تمثل مفاتيح المرور تغييرًا أساسيًا عن الأسرار المشتركة الضعيفة. فبدلاً من كلمات المرور، تستخدم تشفير المفتاح العام. هنا، يقوم مفتاح خاص، مخزن بأمان على جهاز المستخدم، بتوقيع التحديات من الطرف المعتمد (relying party). هذا يثبت أن المستخدم يمتلك المفتاح دون الكشف عن المفتاح نفسه.

هذا التشفير يجعل من الصعب جدًا التصيد الاحتيالي لمفاتيح المرور - وهي ميزة كبيرة، حيث أصبحت هجمات التصيد الاحتيالي (phishing) أكثر خداعًا، وأحيانًا تستخدم التزييف العميق (deepfakes) لتبدو أكثر واقعية. ولأن مفتاح المرور مرتبط بالموقع أو التطبيق المحدد الذي تم إنشاؤه من أجله، لا يمكن للمستخدمين استخدامه عن طريق الخطأ في مواقع مزيفة. هذه مشكلة شائعة في طرق تسجيل الدخول القديمة التي تكون عرضة لمثل هذه الحيل المتقدمة. تمنع مفاتيح المرور أيضًا إعادة استخدام كلمات المرور ومخاطر حشو بيانات الاعتماد (credential stuffing) بعد اختراق البيانات. وأكثر من مجرد الأمان، تجعل مفاتيح المرور تسجيل الدخول أفضل بكثير: فهو أسرع، وغالبًا ما يحتاج فقط إلى مسح بيومتري (مثل Face ID أو بصمة الإصبع)، لذلك لا يضطر المستخدمون إلى تذكر أو كتابة كلمات مرور طويلة. هذا المزيج من الأمان المحسن وسهولة الاستخدام جعلها شائعة بسرعة.

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

على عكس مفاتيح المرور، التي تستخدم بشكل أساسي للمصادقة (إثبات من أنت من خلال إظهار تحكمك في مفتاح خاص)، فإن بيانات الاعتماد الرقمية (المستندة إلى معايير مثل W3C Verifiable Credentials (VCs) أو ISO mdocs) تتعلق بالإشهاد القابل للتحقق بالتشفير (إثبات ما هو صحيح عنك من خلال ادعاءات موقعة رقميًا). تعد القدرة على التحقق بقوة من هذه الادعاءات أمرًا مهمًا، خاصة الآن بعد أن أصبح بإمكان التزييف العميق (deepfakes) إنشاء نسخ مزيفة مقنعة من الأدلة التقليدية. بدون عمليات التحقق المشفرة، قد يجد حتى الخبراء صعوبة في تمييز ما هو حقيقي. فهي تتيح للأشخاص حمل وعرض معلومات موثقة رقميًا - مثل الاسم وتاريخ الميلاد ورخصة القيادة والتعليم أو الشهادات الوظيفية - بطريقة آمنة بالتشفير، وتحترم الخصوصية (من خلال السماح للمستخدمين بمشاركة ما هو ضروري فقط)، ويمكن التحقق منها آليًا.

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

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

يستكشف هذا المقال هذا التآزر. سندرس الاختلافات والتشابهات بينهما، والبروتوكولات التي تمكنهما، واعتمادهما المشترك على الأجهزة الآمنة، وكيف يمكن أن تتشابك في سيناريوهات مثل تسجيل المستخدم الجديد، وتسجيل الدخول مع المصادقة التصعيدية (step-up authentication)، وترحيل الأجهزة. سنتطرق أيضًا إلى كيفية سعي معايير المتصفح الناشئة مثل Digital Credentials API إلى سد الفجوة بين هذين العالمين. يركز هذا المقال بشكل خاص على التفاعل بين هذه التقنيات، مكملاً للاستكشاف التقني الأكثر تعمقًا لـ Digital Credentials API المتاح بالفعل.

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

يقدم الجدول التالي مقارنة عالية المستوى:

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

تتحقق مفاتيح المرور من خلال تفاعل العديد من المعايير الرئيسية:

• WebAuthn (Web Authentication): يحدد معيار W3C هذا واجهة برمجة تطبيقات JavaScript التي تستخدمها تطبيقات الويب للتفاعل مع أدوات المصادقة (authenticators) لتسجيل (navigator.credentials.create()) ومصادقة (navigator.credentials.get()) مفاتيح المرور. إنه يعمل كجسر بين تطبيق الويب الخاص بالطرف المعتمد (Relying Party) ومتصفح المستخدم أو نظام التشغيل. يوسع WebAuthn واجهة برمجة تطبيقات إدارة بيانات الاعتماد (Credential Management API) العامة لـ W3C.

• CTAP (Client to Authenticator Protocol): يحدد CTAP، الذي حدده تحالف FIDO، كيفية تواصل العميل (المتصفح أو نظام التشغيل) مع جهاز أداة المصادقة (authenticator). يمكن أن يكون هذا أداة مصادقة منصة (platform authenticator) مدمجة في الجهاز (باستخدام أجهزة آمنة مثل TPM أو Secure Enclave) أو أداة مصادقة (authenticator) متجولة مثل مفتاح أمان (security key) USB أو حتى هاتف يعمل كأداة مصادقة (authenticator) لجهاز آخر. CTAP2 هو الإصدار المتوافق مع FIDO2 ومفاتيح المرور، ويدعم وسائل نقل مختلفة مثل USB و NFC و Bluetooth Low Energy (BLE).

• إشارات الثقة المتقدمة وربط الجهاز (اعتبارات لمفاتيح المرور المتزامنة): مع تطور مفاتيح المرور لتصبح قابلة للمزامنة عبر الأجهزة ("بيانات اعتماد متعددة الأجهزة")، احتاجت الأطراف المعتمدة (RPs) أحيانًا إلى تحديد الجهاز الفعلي المستخدم أثناء المصادقة لتقييم المخاطر. حاولت الأفكار المبكرة، مثل امتدادات devicePubKey و supplementalPubKeys، حل هذه المشكلة ولكن تم التخلي عنها لاحقًا. تعمل مجموعة عمل إشارات الثقة التابعة لتحالف FIDO الآن على تطوير بدائل. الفكرة الرئيسية هنا هي أن أداة المصادقة التي تحتوي على مفتاح مرور متزامن يمكنها أيضًا إنشاء واستخدام زوج مفاتيح ثانٍ مرتبط بالجهاز. أثناء المصادقة، يمكن لأداة المصادقة بعد ذلك تقديم توقيعات من كل من المفتاح المتزامن الرئيسي وهذا المفتاح الثاني المرتبط بالجهاز. وهذا من شأنه أن يسمح للأطراف المعتمدة بالتعرف على جهاز موثوق به محدد. قد يعني هذا احتكاكًا أقل (على سبيل المثال، تخطي التحديات الإضافية) حتى لو تمت مزامنة مفتاح المرور الرئيسي عبر العديد من الأجهزة، كل ذلك دون فقدان الفائدة الرئيسية لمفاتيح المرور المتزامنة: قابلية الاستخدام عبر الأجهزة. على الرغم من عدم وجود معيار نهائي لهذا حتى الآن، فإن مثل هذه الميزة ستلبي حاجة رئيسية للأطراف المعتمدة التي تتطلب ضمانًا عاليًا، مما يتيح لها اكتشاف استخدام جهاز جديد بشكل أفضل أو تلبية قواعد المصادقة القوية للعملاء (Strong Customer Authentication) (SCA) الداخلية.

وبالمثل، يعتمد النظام البيئي لبيانات الاعتماد الرقمية على مجموعة من البروتوكولات وواجهات برمجة التطبيقات الناشئة ليعمل:

• Digital Credentials API: هذا جهد مواصفات W3C ناشئ يهدف إلى توسيع واجهة برمجة التطبيقات navigator.credentials.get() للسماح لتطبيقات الويب بطلب بيانات اعتماد قابلة للتحقق من محفظة رقمية للمستخدم بطريقة موحدة. إنه يخدم غرضًا مشابهًا لـ WebAuthn ولكنه يركز على VCs بدلاً من مفاتيح المرور.
• OpenID for Verifiable Presentations (OpenID4VP): يحدد هذا بروتوكولًا، مبنيًا على OAuth 2.0، لكيفية قيام جهة التحقق (الطرف المعتمد الذي يطلب بيانات الاعتماد) بطلب VCs من محفظة الحامل. تشمل العناصر الرئيسية presentation_definition (تحديد بيانات الاعتماد والادعاءات المطلوبة)، والمحفظة التي تعمل كخادم تفويض، و vp_token الذي يحمل العرض التقديمي القابل للتحقق (Verifiable Presentation) مرة أخرى إلى جهة التحقق.
• OpenID for Verifiable Credential Issuance (OpenID4VCI): مكملاً لـ OpenID4VP، يوحد هذا المعيار كيفية قيام جهة الإصدار (Issuer) بتسليم VCs إلى محفظة الحامل، مرة أخرى باستخدام آليات OAuth 2.0. وهو يتضمن مفاهيم مثل عروض بيانات الاعتماد، وتدفقات الرمز المصرح به مسبقًا أو رمز التفويض، ونقاط نهاية بيانات الاعتماد المخصصة.
• معايير ISO (مثل ISO/IEC 18013-7, ISO/IEC 23220): هذه المعايير الدولية مهمة بشكل خاص لرخص القيادة المحمولة (mDLs) وأنواع أخرى من المستندات المحمولة (mdoc). يحدد ISO 18013-5 بنية بيانات mDL الأساسية والعرض دون اتصال (NFC, BLE)، بينما يحدد ISO 18013-7 و 23220 آليات العرض عبر الإنترنت، بما في ذلك واجهات برمجة تطبيقات REST وملفات تعريف التكامل مع OpenID4VP (الملحق B من 18013-7). تستفيد منصات مثل Google Wallet و Apple Wallet من معايير ISO هذه.

على الرغم من اختلاف أغراضهما وبروتوكولاتهما، تشترك مفاتيح المرور وبيانات الاعتماد الرقمية في لبنات أساسية:

• التشفير غير المتماثل: كلاهما يعتمد بشكل كبير على أزواج المفاتيح العامة والخاصة. تستخدم مفاتيح المرور المفتاح الخاص لإثبات الحيازة أثناء المصادقة. تستخدم بيانات الاعتماد الرقمية المفتاح الخاص لجهة الإصدار (issuer) لتوقيع بيانات الاعتماد، مما يضمن أصالتها وسلامتها، وقد يستخدم الحامل مفتاحه الخاص لتوقيع عرض تقديمي يحتوي على بيانات الاعتماد.
• الأجهزة الآمنة: حماية المفاتيح الخاصة أمر بالغ الأهمية. تستفيد كلتا التقنيتين بشكل كبير من مكونات الأجهزة الآمنة المدمجة في الأجهزة الحديثة:
  • TPM (Trusted Platform Module): شريحة مخصصة توجد غالبًا في أجهزة الكمبيوتر المحمولة والمكتبية، وتوفر إنشاء مفاتيح آمنة وتخزينها وعمليات تشفير. يشيع استخدامها من قبل أدوات مصادقة (authenticators) المنصة مثل Windows Hello.
  • Secure Enclave: مدير مفاتيح قائم على الأجهزة من Apple، معزول عن المعالج الرئيسي في أجهزة iPhone و iPad و Mac، ويستخدم لحماية البيانات الحساسة بما في ذلك المفاتيح الخاصة لمفاتيح المرور.
  • Android Keystore System / StrongBox Keymaster: يوفر Android مخزن مفاتيح مدعومًا بالأجهزة، وغالبًا ما يتم تنفيذه باستخدام معالج آمن مخصص (StrongBox Keymaster)، مما يوفر حماية قوية للمفاتيح المشفرة على أجهزة Android. بينما تستخدم بعض برامج إدارة كلمات المرور اسم "Strongbox"، فإن عنصر الأجهزة الآمن الأساسي الذي يوفره نظام التشغيل هو الممكن الرئيسي هنا.

إن استخدام نفس عناصر الأجهزة الآمنة (TPM, Secure Enclave, مخزن المفاتيح المدعوم بالأجهزة في Android) لكل من عمليات مفاتيح المرور وربما لتأمين المفاتيح الخاصة داخل المحافظ الرقمية يخلق تآزرًا كبيرًا. لا تحتاج المنصات إلى شرائح آمنة منفصلة لكل وظيفة. بدلاً من ذلك، يمكنها استخدام قاعدة أجهزة واحدة قوية وواجهات برمجة تطبيقات نظام التشغيل ذات الصلة (مثل تلك الخاصة بـ Android Keystore أو Secure Enclave من Apple) لحماية كل من بيانات اعتماد المصادقة (مفاتيح المرور) وبيانات اعتماد الإشهاد (attestation) (VCs) بقوة. هذا يجعل التطوير أسهل، ويحسن اتساق الأمان، ويستخدم استثمارات المنصة الحالية بشكل جيد.

علاوة على ذلك، تعد واجهة برمجة تطبيقات إدارة بيانات الاعتماد في المتصفح (navigator.credentials) طبقة تنظيمية رئيسية. بعد أن تم توسيعها أولاً بواسطة WebAuthn لمفاتيح المرور، يتم الآن توسيعها بشكل أكبر بواسطة Digital Credentials API لـ VCs. يشير هذا إلى خطة واضحة: منح الأطراف المعتمدة طريقة رئيسية واحدة لطلب بيانات اعتماد مختلفة، ومنح المستخدمين طريقة مألوفة لاختيارها (مثل من خلال مدير بيانات الاعتماد في Android أو مديري كلمات المرور المدمجين في المتصفح). وهذا من شأنه إخفاء التفاصيل الفنية المعقدة لبروتوكولات مثل CTAP و OID4VP و ISO، مما يسهل الأمور على المطورين والمستخدمين.

من منظور الطرف المعتمد (Relying Party) (RP)، يعد فهم كيفية دمج واستخدام مفاتيح المرور وبيانات الاعتماد الرقمية بشكل فعال أمرًا بالغ الأهمية لتعزيز الأمان وتحسين تجربة المستخدم وتلبية المتطلبات التنظيمية. يحلل هذا القسم كيف يمكن للأطراف المعتمدة نشر هذه التقنيات عبر سيناريوهات وأنظمة بيئية مشتركة مختلفة.

تختلف استراتيجية التكامل المثلى لمفاتيح المرور وبيانات الاعتماد الرقمية بشكل كبير بناءً على حالة الاستخدام المحددة وملف المخاطر والمتطلبات المرتبطة بها. يقدم الجدول التالي مقارنة عالية المستوى عبر السيناريوهات الشائعة:

مقارنة سيناريوهات النظام البيئي

مفتاح:

• دور VC 🆔: يصف الدور أثناء التفاعل الرئيسي، مع الاعتراف بأن VCs غالبًا ما تستخدم للتسجيل الأولي/KYC عبر السيناريوهات.
• ربط بالجهاز؟ 🔗: يشير إلى الحاجة إلى ربط صريح بالجهاز يتجاوز ربط مصدر مفتاح المرور القياسي، وهو أمر مهم بشكل خاص لمفاتيح المرور المتزامنة.
• تفويض محفظة EUDI للاتحاد الأوروبي*: يعكس هذا السيناريو المتطلبات بموجب لائحة eIDAS 2 القادمة، والتي من المتوقع أن تطبق بعد حوالي 36 شهرًا من دخول القوانين التنفيذية النهائية حيز التنفيذ (على الأرجح في أواخر عشرينيات القرن الحالي).

تقدم هذه المقارنة نظرة عامة سريعة؛ تتعمق الأقسام التالية في تفاصيل كل سيناريو من منظور تكامل الطرف المعتمد.

• الهدف: وصول سريع ومنخفض الاحتكاك مع أمان أساسي جيد.
• التدفق المحتمل:
  • المصادقة الأساسية: ستهيمن مفاتيح المرور. مقاومتها للتصيد الاحتيالي وتجربة المستخدم السلسة (غالبًا ما تكون مجرد بصمة بيومترية/PIN) تجعلها مثالية لاستبدال كلمات المرور في سيناريوهات تسجيل الدخول المتكررة.
  • دور بيانات الاعتماد الرقمية: ضئيل لتسجيل الدخول الأساسي. قد يتم استخدام VCs اختياريًا بعد تسجيل الدخول لإجراءات محددة مثل التحقق من العمر (على سبيل المثال، شراء سلع مقيدة)، أو التخصيص بناءً على سمات موثقة (على سبيل المثال، حالة الولاء)، أو إكمال الملف الشخصي المعجل أثناء التسجيل الأولي.
• التفاعل: يتعامل مفتاح المرور مع تسجيل الدخول الأساسي؛ يتم حجز VCs للتفاعلات الاختيارية القائمة على السمات.

• الهدف: تسجيل دخول عالي الضمان، وعند الضرورة، تأكيد هوية موثق.
• التدفق المحتمل:
  • مفاتيح المرور كـ 2FA/MFA مستقلة: تلبي مفاتيح المرور بطبيعتها متطلبات المصادقة الثنائية (two-factor authentication) عندما يحدث التحقق من المستخدم (user verification) (PIN/بصمة بيومترية) أثناء عملية تسجيل الدخول. فهي تجمع بين:
    • الحيازة: إثبات التحكم في المفتاح الخاص.
    • المعرفة/السمة الذاتية: التحقق من المستخدم (user verification) عبر PIN أو القياسات الحيوية. هذا يجعل تسجيل الدخول بمفتاح المرور نفسه طريقة MFA قوية ومقاومة للتصيد الاحتيالي، كافية للعديد من سيناريوهات الضمان العالي دون الحاجة إلى خطوة ثانية منفصلة لمجرد تحقيق 2FA.
  • تصعيد للتحقق من الهوية (مرة واحدة): تأتي الحاجة الرئيسية لخطوة إضافية مع بيانات الاعتماد الرقمية عندما يجب على الخدمة التحقق صراحة من الهوية بما يتجاوز مجرد مصادقة مستخدم عائد. هذا النوع من التحقق القوي والمشفر أمر حيوي عندما يمكن للتزييف العميق (deepfakes) تزوير الهوية المرئية أو المستندة إلى المستندات بشكل مقنع. عندها فقط يمكن للإثبات الرقمي المشفر من مصدر موثوق أن يؤكد سمة ما بشكل موثوق. قد يكون هذا ضروريًا:
    • أثناء التسجيل الأولي.
    • لإجراءات محددة عالية المخاطر تتطلب سمات هوية مؤكدة. في هذه الحالات، يطلب الطرف المعتمد عرض بيان اعتماد قابل للتحقق (Verifiable Credential) محدد (مثل PID، بيانات اعتماد الهوية الوطنية) من محفظة المستخدم بعد تسجيل الدخول بمفتاح المرور.
  • الهوية للاسترداد: بمجرد التحقق بقوة من هوية المستخدم (على سبيل المثال، عبر خطوة تصعيد عرض VC)، يمكن الاستفادة من معلومات الهوية الموثقة هذه في تدفقات استرداد الحساب الآمنة. على سبيل المثال، إذا فقد المستخدم جميع أدوات المصادقة (authenticators) الخاصة بمفتاح المرور، فإن تقديم بيانات اعتماد هوية عالية الضمان يمكن أن يكون جزءًا من عملية استعادة الوصول وتسجيل مفاتيح مرور جديدة.
• التفاعل: توفر مفاتيح المرور 2FA/MFA قوية ومستقلة للمصادقة. يتم استخدام VCs بشكل استراتيجي للتحقق الصريح من الهوية عند الحاجة، ويمكن لهذه الهوية الموثقة أيضًا دعم آليات استرداد الحساب الآمنة.

• الهدف: إتمام عملية شراء أو بدء دفع مبسط وآمن، مع تقليل احتكاك المستخدم إلى الحد الأدنى.
• التدفق المحتمل:
  • المصادقة للدفع: تعتبر مفاتيح المرور مثالية لمصادقة المستخدم لدى حساب مزود خدمة الدفع (Payment Service Provider) (PSP) الخاص به (مثل PayPal) أو مباشرة داخل تدفق الدفع لدى التاجر (merchant). هذا يحل محل كلمات المرور ويوفر تأكيدًا سريعًا وآمنًا لبدء الدفع.
  • التسجيل/KYC: تظل VCs حاسمة خلال مرحلة التسجيل أو إعداد الحساب مع PSP أو التاجر (merchant)، حيث توفر معلومات هوية موثقة (فحوصات KYC/AML) ضرورية لتمكين قدرات الدفع في المقام الأول.
  • مخاوف احتكاك المعاملات: إن إدخال خطوة عرض بيان اعتماد قابل للتحقق (Verifiable Credential) منفصلة أثناء تدفق تفويض الدفع الأساسي (مما يتطلب التفاعل مع محفظة هوية رقمية) من شأنه أن يضيف احتكاكًا كبيرًا مقارنة بخطوة تأكيد سلسة بمفتاح المرور. من المرجح أن يؤدي هذا الاضطراب في تجربة المستخدم إلى الإضرار بمعدلات التحويل وبالتالي فهو غير مناسب لسيناريوهات الدفع النموذجية منخفضة الاحتكاك.
• التفاعل: يؤمن مفتاح المرور المصادقة لعملية الدفع نفسها. تتعامل VCs مع إثبات الهوية/KYC الضروري، والذي غالبًا ما يكون لمرة واحدة، والمطلوب لإنشاء حساب الدفع، ولكن يتم إبعاده عن خطوة تأكيد الدفع الحاسمة والحساسة للاحتكاك. (يتم استكشاف الموضوع المعقد لاستخدام بيانات الاعتماد الرقمية مباشرة كأدوات دفع، بما في ذلك كيف يمكن لأنواع المحافظ المختلفة وواجهات برمجة تطبيقات المتصفح الناشئة تمكين أو التفاعل مع VCs الخاصة بالدفع، بالتفصيل في مقالنا التكميلي القادم: بيانات الاعتماد الرقمية والدفع).

• الهدف: تأمين الوصول إلى الخدمات المصرفية مع تقليل كبير في الاحتيال، لا سيما المتعلق بالتصيد الاحتيالي، عن طريق الترقية من طرق المصادقة القديمة.
• التدفق المحتمل:
  • استبدال MFA القديمة: تعتمد العديد من المؤسسات المالية حاليًا على كلمات المرور مع عوامل ثانية قابلة للتصيد مثل رموز OTP عبر الرسائل القصيرة. تقدم مفاتيح المرور بديلاً أفضل بكثير، حيث توفر مصادقة قوية مقاومة بطبيعتها للتصيد الاحتيالي في إيماءة مستخدم واحدة.
  • تسجيل الدخول الأساسي باستخدام مفاتيح المرور: يعزز اعتماد مفاتيح المرور لتسجيل الدخول الأساسي الأمان على الفور بسبب مقاومتها للتصيد الاحتيالي. تخفف الطبيعة المشفرة لمفاتيح المرور من أكثر نواقل الهجوم شيوعًا التي تعاني منها بيانات الاعتماد التقليدية.
  • التصعيد القائم على المخاطر - دراسة متأنية لإشارات الجهاز: بالنسبة للعمليات عالية المخاطر (مثل التحويلات الكبيرة، تغيير تفاصيل الاتصال)، قد تفكر المؤسسات المالية في التحقق التصعيدي. في حين أن إشارات ربط الجهاز المرتبطة بمفاتيح المرور هي خيار، يجب تقييم ضرورتها بعناية. مقاومة التصيد الاحتيالي لمصادقة مفتاح المرور الأساسية نفسها تخفف بشكل كبير من العديد من المخاطر.
  • الأمان القائم على النتائج وتقليل الاحتيال: يعد الانخفاض الكبير في مخاطر التصيد الاحتيالي الذي تحققه مفاتيح المرور عاملاً حاسماً. يمكن أن يؤدي النهج القائم على النتائج للأمان، مع التركيز على قوة ومقاومة طريقة المصادقة للتصيد الاحتيالي، إلى تقليل كبير في الاحتيال. وزن عامل مقاوم للتصيد الاحتيالي مثل مفتاح المرور أعلى بكثير من إضافة المزيد من العوامل القابلة للتصيد. يجب أن يكون هذا محوريًا في استراتيجية المؤسسة المالية عند الانتقال من الطرق القديمة.
  • VCs للتسجيل/إثبات الهوية: كما هو الحال في السيناريوهات الأخرى، تظل VCs ضرورية لـ KYC/AML الأولي القوي ولتحديث سمات هوية العميل بشكل آمن باستخدام معلومات موثقة، مما يؤسس أساسًا موثوقًا به للعلاقة المصرفية.
• التفاعل: تعمل مفاتيح المرور كطريقة مصادقة أساسية قوية ومقاومة للتصيد الاحتيالي، مما يقلل بشكل كبير من مخاطر الاحتيال من الأنظمة القديمة. إشارات الجهاز للتصعيد هي خيار تكتيكي. يجب أن تسترشد القوة الكامنة لمفاتيح المرور بموقف أمني قائم على المخاطر، مما قد يقلل من الاعتماد المفرط على عوامل إضافية أقل مقاومة للتصيد الاحتيالي. توفر VCs ضمان هوية أساسي.

• الهدف: الامتثال للوائح eIDAS 2 (المادة 5f) التي تتطلب قبول محفظة الهوية الرقمية للاتحاد الأوروبي من قبل أطراف معتمدة محددة (الهيئات العامة، الكيانات الخاصة الكبيرة في القطاعات المنظمة، VLOPs)، مما يتيح كلاً من تسجيل الدخول باسم مستعار يحافظ على الخصوصية والتحقق من الهوية/السمات عالي الضمان عند الاقتضاء القانوني.
• التدفق المحتمل:
  • تسجيل الدخول باسم مستعار (افتراضي): يبدأ المستخدم تسجيل الدخول. يطلب الطرف المعتمد المصادقة عبر محفظة EUDI. تستخدم المحفظة "مفتاح الاسم المستعار" المدمج بها - وهو مفتاح مقيم (resident key) من نوع WebAuthn مرتبط بالأجهزة ومخصص للطرف المعتمد ومخزن في العنصر الآمن المعتمد بالجهاز (WSCD) - لمصادقة المستخدم. يوفر هذا مصادقة قوية ومتوافقة مع SCA (حيازة + تحقق من المستخدم (user verification)) مع الحفاظ على هوية المستخدم المدنية مجهولة الاسم بشكل افتراضي.
  • تصعيد للهوية/السمات (مطلوب قانونًا): فقط وفقط إذا كان لدى الطرف المعتمد أساس قانوني محدد بموجب قانون الاتحاد أو القانون الوطني (مثل PSD2، AML، تسجيل الاتصالات) لطلب التحقق من الهوية أو سمات محددة، فإنه يبدأ خطوة ثانية. يطلب الطرف المعتمد عرضًا (عبر OpenID4VP) لبيانات تعريف الشخص (PID) اللازمة أو إشهاد (attestation) مؤهل للسمات (QAA) من المحفظة. يجب على المستخدم الموافقة صراحة على مشاركة هذه البيانات المحددة للهوية.
  • مصادقة المحفظة والطرف المعتمد: يتضمن التدفق مصادقة متبادلة. يصادق الطرف المعتمد على نفسه للمحفظة (بناءً على تسجيله الرسمي)، وتشهد المحفظة على أصالتها وصحة بيانات الاعتماد للطرف المعتمد، مستفيدة من الأجهزة الآمنة (WSCD) والبنية التحتية للشهادات المرتبطة بها.
• التفاعل: تعمل محفظة EUDI كمصادق موحد. يتعامل مفتاح المرور WebAuthn المدمج بها (مفتاح الاسم المستعار) مع تسجيل الدخول القياسي، مما يوفر مصادقة قوية تحافظ على الخصوصية. يتم استدعاء قدرات VC الخاصة بالمحفظة بشكل انتقائي للكشف الصريح عن الهوية أو السمات المفروض قانونًا، مما يضمن تقليل البيانات بشكل افتراضي.

يتطلب التنقل في هذا المشهد المتطور تخطيطًا استراتيجيًا. فيما يلي اعتبارات رئيسية للأطراف المعتمدة (RPs)

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

بينما تقدم مفاتيح المرور نفسها خطوة مهمة نحو المصادقة القوية ويمكن أن تلبي متطلبات المصادقة القوية للعملاء (Strong Customer Authentication) (SCA)، قد يكون لدى بعض المؤسسات أطر امتثال داخلية ذات تفسيرات أكثر صرامة أو مخاوف محددة، لا سيما فيما يتعلق بمفاتيح المرور المتزامنة. بالنسبة للأطراف المعتمدة (RPs) التي تواجه مثل هذه السيناريوهات حيث تسعى أقسام الامتثال إلى مزيد من الضمانات، من المفيد معرفة أنه يمكن اتخاذ تدابير إضافية لتكملة عمليات نشر مفاتيح المرور. يمكن أن تساعد هذه في معالجة فجوات SCA المتصورة أو تلبية تلك المتطلبات الداخلية المشددة. تتمثل إحدى الاستراتيجيات الشائعة في الاستفادة من إشارات ثقة الجهاز، وهو نهج تتبعه خدمات مثل PayPal.

على سبيل المثال، يسمح PayPal للمستخدمين بتمييز جهاز على أنه "متذكر" كما هو موضح في صفحة المساعدة الخاصة بهم:

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

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

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

على الرغم من أن هذه الامتدادات المحددة (devicePubKey و supplementalPubKeys) قد تم إيقافها، إلا أن تحدي الحصول على إشارات ربط أقوى بالجهاز لمفاتيح المرور المتزامنة لا يزال قائمًا. لذلك يجب على الأطراف المعتمدة مراقبة تطوير وتوحيد الحلول اللاحقة في هذا المجال. يمكن أن تساعد هذه الحلول الأطراف المعتمدة على الحكم بشكل أفضل على المخاطر (على سبيل المثال، التمييز بين تسجيل الدخول من جهاز معروف وموثوق به وآخر متزامن حديثًا) دون إجبار جميع المستخدمين على استخدام مفاتيح مرور مرتبطة بالجهاز وأقل ملاءمة. يقدم هذا السياق للأطراف المعتمدة خيارًا أكثر تعقيدًا من مجرد "متزامن مقابل مرتبط بالجهاز". توفر مفاتيح المرور المتزامنة (عادةً ما تكون متوافقة مع AAL2) أكبر قدر من الراحة وأفضل فرصة للاعتماد، وهو أمر حيوي للتطبيقات الاستهلاكية. توفر مفاتيح المرور المرتبطة بالجهاز (ربما AAL3) أعلى ضمان ولكن يمكن أن تكون أصعب في الاستخدام. كان الهدف من الامتدادات المتوقفة هو إيجاد طريقة وسط - تحسين الأمان للمفاتيح المتزامنة عن طريق إضافة إشارة ثقة خاصة بالجهاز. قد يساعد هذا في تقليل بعض المخاطر إذا تم اختراق مزامنة السحابة، دون فقدان كل راحة المزامنة. لذلك يجب على الأطراف المعتمدة البحث عن حلول لاحقة تهدف إلى القيام بذلك. ستعتمد أفضل استراتيجية على مدى تحمل الطرف المعتمد للمخاطر، وقاعدة المستخدمين، ومدى نضج أي معايير جديدة.

إلى جانب الآليات المحددة داخل WebAuthn لثقة الجهاز، بدأت بعض الأطراف المعتمدة (RPs) - لا سيما تلك الموجودة في قطاعات مثل الخدمات المصرفية والتأمين وخدمات الدفع - في تقييم بيانات الاعتماد الرقمية (Verifiable Credentials, or VCs) كعنصر مكمل، أو حتى خطوة تالية، في استراتيجيات الهوية والأمان الخاصة بهم.

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

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

بينما توفر مفاتيح المرور مصادقة مباشرة، تتم إدارة بيانات الاعتماد الرقمية (VCs) وتقديمها إلى الأطراف المعتمدة من خلال محافظ الهوية الرقمية. تتطور هذه المحافظ، سواء كانت حلول منصة أصلية (مثل Apple Wallet, Google Wallet) أو تطبيقات طرف ثالث (مثل محفظة EUDI)، لاستخدام معايير المتصفح الناشئة مثل Digital Credentials API للتحقق من الهوية عبر الإنترنت بشكل أكثر سلاسة (مثل التحقق من العمر، مشاركة سمات الهوية الرقمية).

إن الآليات التفصيلية لأنواع المحافظ المختلفة، واستراتيجيات المنصة المحددة لتكامل VC (بما في ذلك تركيز Apple على mDoc لتفاعلات المتصفح مقابل دعم Android الأوسع لـ OpenID4VP عبر مدير بيانات الاعتماد الخاص به)، وكيف تسهل هذه المحافظ إشهاد (attestation) السمات، والاعتبارات المنفصلة تمامًا لأي وظائف دفع هي مواضيع معقدة. يتم استكشافها بعمق في مقالنا التكميلي القادم: بيانات الاعتماد الرقمية والمدفوعات.

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

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

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

• نشر مفاتيح المرور في كل مكان اليوم: المعايير ناضجة، ودعم المنصات واسع الانتشار، والفوائد على كلمات المرور واضحة وكبيرة. اجعل مفاتيح المرور الهدف الافتراضي لمصادقة المستخدم لتعزيز الأمان وسهولة الاستخدام على الفور.
• إضافة خطوة تصعيد بالمحفظة حيث يهم AML/KYC: للعمليات التي تتطلب ضمانًا أعلى أو سمات موثقة محددة - مثل تلبية لوائح مكافحة غسيل الأموال (AML) / اعرف عميلك (KYC)، أو إجراء تحقق موثوق من العمر، أو تأكيد المؤهلات المهنية - قم بدمج تدفقات عرض بيان الاعتماد القابل للتحقق (Verifiable Credential) للحصول على سمات يمكن التحقق منها بالتشفير، والتي لا غنى عنها للثقة في الهوية والادعاءات في عصر التزوير الرقمي المتطور والتزييف العميق. استخدم Digital Credentials API حيثما أمكن، ولكن قم بتنفيذ حلول بديلة قوية باستخدام رمز الاستجابة السريعة/الرابط العميق لضمان الوصول عبر المنصات حتى تستقر واجهة برمجة التطبيقات. يوفر هذا ضمانًا عاليًا مستهدفًا دون إثقال كاهل كل عملية تسجيل دخول.

بالنظر إلى المستقبل، يمكننا أن نتوقع المزيد من التقارب والتحسينات:

• تحسين قابلية نقل بيانات الاعتماد: من المرجح أن تتحسن طرق النقل من جهاز إلى جهاز. قد يتجاوز هذا مصادقة CTAP 2.2 عبر الأجهزة لمفاتيح المرور ليشمل طرقًا أكثر سلاسة لنقل VCs بين المحافظ، على الرغم من أن التوحيد القياسي هنا ليس متقدمًا بنفس القدر.
• واجهات برمجة تطبيقات متصفح موحدة: من المحتمل أن تنضج Digital Credentials API وتدعم بشكل أكثر اتساقًا عبر المتصفحات. سيوفر هذا للأطراف المعتمدة طريقة أكثر توحيدًا لطلب كل من مفاتيح المرور و VCs من خلال navigator.credentials.
• تجربة مستخدم موحدة: في نهاية المطاف، يجب أن يرى المستخدمون فرقًا تقنيًا أقل بين المصادقة باستخدام مفتاح مرور وتقديم السمات باستخدام VC. من المرجح أن تدير مديرو بيانات الاعتماد والمحافظ في المنصات هذه التفاعلات بسلاسة خلف الكواليس. سيستخدمون أدوات تشفير مشتركة وأجهزة آمنة، مما يتيح للمستخدمين ببساطة الموافقة على الطلبات بمطالبات بيومترية أو PIN مألوفة، بغض النظر عما إذا كان يتم استخدام مفتاح مرور أو VC. علاوة على ذلك، يمكن لمفاهيم مثل المصادقة السلبية المستمرة (Continuous Passive Authentication - CPA)، التي تتحقق باستمرار من المستخدمين في الخلفية باستخدام القياسات الحيوية السلوكية وإشارات أخرى، أن تعزز هذا الأمان السلس، وربما تعمل جنبًا إلى جنب مع المصادقات النشطة مثل مفاتيح المرور.

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