مدونات ICANN

اقرأ مدونات ICANN لتبقى على اطلاع على آخر أنشطة وضع السياسات والمحافل الإقليمية وغيرها.

مستجدات SSAD ODP: منهجية الامتثال التعاقدي والتحقق من الهوي

2 نوفمبر 2021
بقلم

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

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

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

الامتثال التعاقدي

في توصيات SSAD، هناك ناحيتان إثنتان سيكون الامتثال التعاقدي في ICANN مشارك بشأنهما:

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

سوف يتعامل الامتثال التعاقدي مع هذه الشكاوى باستخدام نفس الإجراءات القياسية المعمول بها بالفعل. وسيتم تلقي الشكاوى المتعلقة بنظام SSAD ومعالجتها من خلال نماذج الشكاوى العامة في بوابة خدمات التسمية (NSp) التي تؤدي إلى فتح ملف منفرد لكل حالة وقضية. وإذا لزم الأمر، يمكن وضع عمليات آلية للتعامل مع حالات خرق اتفاقية مستوى الخدمة SLA.

أسئلة موجهة للمجتمع

  • هل تغطي النواحي المحددة في التوصيات جميع المجالات المقصودة التي يمكن للامتثال التعاقدي أن يفرض انفاذ السياسة بشأنها؟

منهجية التحقق من الهوية

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

  • الأشخاص الطبيعيون والاعتباريون غير الحكوميين (المشار إليهم في التوصية 1).
    • بالنسبة لهؤلاء المستخدمين، ستعمل ICANN كهيئة اعتماد مركزي (AA) لهم.
  • الكيانات الحكومية والمنظمات الحكومية الدولية (المبينة في التوصية 2).
    • اعتماد المستخدمين الحكوميين خارج نطاق هيئة الاعتماد AA المركزي.

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

وتشمل الطرق التي تقترحها ICANN لتحديد هوية الأشخاص الطبيعيين:

  • استخدام نظام التعريف الإلكتروني المؤهل (eID)، أو
  • حيازة هوية حكومية معترف بها مع صورة، أو
  • حيازة هوية حكومية معترف بها مع قدرات إلكترونية

بينما تشمل الطرق التي تقترحها ICANN للتحقق من الانتساب (مع شخص اعتباري) ما يلي:

  • سيقدم الشخص الطبيعي الذي تم التحقق منه (الموضح أعلاه) المعلومات المتعلقة بالشخص الاعتباري أو الانتماء بما في ذلك الاسم القانوني أو الوضع القانوني للمؤسسة أو العنوان أو المعرّف الضريبي أو أي معرف آخر، والذي سيتم التحقق منه بعد ذلك بواسطة هيئة الاعتماد المركزي Central AA أو موفر الهوية المعني.

وتشمل الطريقة التي تقترحها ICANN لتحديد هوية المستخدمين:

  • قد يؤكد شخص طبيعي تم التحقق منه داخل النظام من أنه يمثل كيانًا قانونياً لأغراض طلب بيانات غير عامة.
  • وسيقدم الممثل معلومات مختلفة بشأن الشخص الاعتباري الذي يتم تمثيله، على سبيل المثال، الاسم القانوني، الصفة القانونية، العنوان الفعلي أورقم الهوية / الرقم الضريبي الخاص بالممثَّل عنه.
  • تأكيد العلاقة بين الممثل والممثَل عنه عبر جهة الاتصال (PoC). يجب تحديد جهة الاتصال PoC داخل نظام SSAD ويجب أن يكون تابعًا للممثَّل عنه.
  • وتقدم جهة الاتصال PoC شهادة حسن السمعة (أو ما يكافؤها) بخصوص الممثل عنه.

يوجد المزيد من المعلومات حول طرق التحقق من الهوية والعمليات متوفرة في شرائح العرض للندوة عبر الويب هنا.

أسئلة موجهة للمجتمع

  • هل يوفّر المنهج المقترح مستوىً مناسب من التحقق من الهوية فيما يتعلق بـ:
    • هوية الأشخاص الطبيعيين الذين قد يصبحون مستخدمين لنظام SSAD؟
    • هوية الأشخاص الاعتباريين التي ستكون موجودة داخل SSAD لأغراض توثيق الانتماء من قبل المستخدمين؟
    • العلاقة بين المنظمات الممثَلة والمستخدمين؟
  • هل يمثل النهج المقترح مستوى معقول من الجهد المبذول لأجل:
    • المستخدمين الذين يرغبون بأن يُصبحوا معتمَدين؟
    • أولئك المطالبين بالإعلان عن الانتماء والمحافظة عليه؟
    • أولئك المطالبين بالإعلان عن التمثيل والمحافظة عليه؟

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

إن كان لديك سؤالاً أو تود أن تقدم تعقيباً حول الأسئلة المبينة أعلاه، يرجى إرساله إلى البريد الإلكتروني: ODP-SSAD@icann.org. يرجى الانتباه إلى أنه ستتتم أرشفة كافة الاقتراحات على الإنترنت وستكون متاحة للاطلاع عليها من قبل الجميع هنا.

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

Authors

Eleeza Agopian

Eleeza Agopian

Vice President, Strategic Initiatives