#dusk $DUSK @Dusk هل يعني وجود خدمة الإثباتات الصفرية المعرفة أنه يجب أن “تُدخِلَك” في كل الأحوال؟ عندما قرأتُ مستندات Citadel 2 الخاصة بـ @Dusk ، وجدت أن الجواب بالعكس. فالعقد Citadel لا يقوم إلا بالتحقق من أن الجلسة صالحة من الناحية التشفيرية؛ أما من يقرر فعلاً السماح بالدخول من عدمه فما يزال هو مزوّد الخدمة (Service Provider). هذا الحدّ يمكن التغاضي عنه بسهولة عبر عبارة مثل «لا حاجة لكشف بياناتك الشخصية». يبدأ المستخدم بالحصول على بيانات الاعتماد من مزوّد التراخيص (License Provider) ثم يولّد إثباتًا يثبت أنه يملك ترخيصًا مُسجّلًا وصادرًا من جهة موثوقة؛ وعلى السلسلة لا يظهر أيّ نوع من الوثائق (الهوية) استخدمه. لكن عند بوابة الخدمة، يتعين على مزوّد الخدمة تحديد من يثق به من مزوّدي التراخيص (LP) وأي سمات يقبلها، كذلك يجب التحقق مما إذا كانت الجلسة منتهية أو مُلغاة، وهل يمكن إعادة استخدام الكوكيز أم لا.
أرى أن هذا أكثر صراحةً من Citadel 2؛ فهو لا يلفّ «صحة الإثبات» في صورة «صلاحية تلقائية للموافقة»، بل يفصل التحقق التشفيري عن الترخيص الخاص بالأعمال إلى خطوتين. بالنسبة للمستخدم يقلّ انكشاف المعلومات الشخصية، وبالنسبة لطرف الخدمة لا تختفي القواعد، بل تنتقل من جمع مجموعة كاملة من البيانات إلى اختيار مصادر الثقة وفحص حالة الجلسة. أما سيناريو الضغط فهو أيضًا محدّد: قد يكون إثبات المستخدم صحيحًا بالكامل، لكن الخدمة ترفض الوصول لأن مزوّد الخدمة لا يثق بالـ LP الذي أصدر الترخيص، أو لأنه يكتشف أن الجلسة منتهية. قد يظن المستخدم أن المشكلة في السلسلة، بينما يرى مزوّد الخدمة أن ما يحدث هو مجرد تنفيذ سياساتهم. وإذا كانت الصفحة تعرض فقط «فشل التحقق»، فلن يجد أي طرف نقطة المسؤولية الحقيقية.
لذا، عند النظر في تصميم هوية DUSK، لا أظنه يسأل فقط عن مقدار ما يمكن إخفاؤه من السمات؛ بل أريد معرفة ما إذا كانت كل تطبيقاتٍ تشرح بوضوح الفرق بين «صحة الإثبات» و«السماح عبر الخدمة». إن Citadel 2 الخاصة بـ @Dusk يمكنها تقليل الإفصاح غير الضروري للمعلومات، لكنها لا تستطيع أن تقرر لمن يثق التطبيق. والأكثر جدارة بالملاحظة في المستقبل هو: عندما يُرفض الوصول، هل سيتمكن المستخدم من معرفة ما إذا كانت المشكلة في الإثبات أو في بيانات الاعتماد أم في سياسة الخدمة؟ #dusk
أرى أن هذا أكثر صراحةً من Citadel 2؛ فهو لا يلفّ «صحة الإثبات» في صورة «صلاحية تلقائية للموافقة»، بل يفصل التحقق التشفيري عن الترخيص الخاص بالأعمال إلى خطوتين. بالنسبة للمستخدم يقلّ انكشاف المعلومات الشخصية، وبالنسبة لطرف الخدمة لا تختفي القواعد، بل تنتقل من جمع مجموعة كاملة من البيانات إلى اختيار مصادر الثقة وفحص حالة الجلسة. أما سيناريو الضغط فهو أيضًا محدّد: قد يكون إثبات المستخدم صحيحًا بالكامل، لكن الخدمة ترفض الوصول لأن مزوّد الخدمة لا يثق بالـ LP الذي أصدر الترخيص، أو لأنه يكتشف أن الجلسة منتهية. قد يظن المستخدم أن المشكلة في السلسلة، بينما يرى مزوّد الخدمة أن ما يحدث هو مجرد تنفيذ سياساتهم. وإذا كانت الصفحة تعرض فقط «فشل التحقق»، فلن يجد أي طرف نقطة المسؤولية الحقيقية.
لذا، عند النظر في تصميم هوية DUSK، لا أظنه يسأل فقط عن مقدار ما يمكن إخفاؤه من السمات؛ بل أريد معرفة ما إذا كانت كل تطبيقاتٍ تشرح بوضوح الفرق بين «صحة الإثبات» و«السماح عبر الخدمة». إن Citadel 2 الخاصة بـ @Dusk يمكنها تقليل الإفصاح غير الضروري للمعلومات، لكنها لا تستطيع أن تقرر لمن يثق التطبيق. والأكثر جدارة بالملاحظة في المستقبل هو: عندما يُرفض الوصول، هل سيتمكن المستخدم من معرفة ما إذا كانت المشكلة في الإثبات أو في بيانات الاعتماد أم في سياسة الخدمة؟ #dusk
