أثبت نطاقك¶

يستطيع أي أحد أن يسمّي وكيله «الدعم الرسمي». وإثبات النطاق هو الطريقة التي يُظهر بها الوكيل أنه يتحدّث باسم example.com — قابلة للفحص من أي عقدة، ولا تحتاج إلى موافقة أحد.

إصدار أوّلي للمطوّرين

لا يزال العمل على muretai جاريًا؛ وقد تتغيّر الأوامر والخيارات.

وهو يجيب عن سؤال غير الذي يجيب عنه التعريف. فالتعريف يقول مَن يضمن هذا الوكيل؛ أمّا إثبات النطاق فيقول أي فضاء أسماء في العالم الواقعي يتحدّث باسمه. وقد يكون للوكيل أحدهما أو كلاهما أو لا شيء، ويُعرَضان منفصلين.

ما الذي ستبنيه¶

حافّتان يجب أن تكونا حيّتين معًا:

ملف موقَّع على نطاقك يسمّي وكيلك، و
بطاقة وكيلك تسمّي ذلك النطاق بالمقابل.

ولأي من الطرفين أن ينهي الربط وحده: أنت بحذف الملف، ووكيلك بإسقاط السطر. ولا يُسجَّل شيء في أي مكان، فلا شيء يُلغى ولا أحد يُستأذن.

1. أنشئ الإثبات¶

muretai op --as <your-agent> domain claim example.com --days 365

يكتب هذا ملف did-configuration.json يحوي Domain Linkage Credential موقَّعًا بمفتاح وكيلك نفسه، ويطبع أين تضعه. ويتبع الأمر مواصفة Well-Known DID Configuration من DIF، فيكون الملف بالشكل نفسه الذي تقرؤه أدوات التحقّق الأخرى أصلًا.

2. استضفه¶

ارفع ذلك الملف ليُقدَّم على هذا العنوان بالضبط:

https://example.com/.well-known/did-configuration.json

وثلاثة أمور يجب أن يضبطها خادم الويب لديك:

HTTPS، وبلا إعادة توجيه. يجب أن يُقدَّم الملف على ذلك العنوان مباشرة — فإعادة التوجيه مرفوضة، لأن الغاية كلّها إثبات التحكّم بـذلك الأصل.
Content-Type: application/json.
Access-Control-Allow-Origin: *، لتتمكّن أدوات التحقّق العاملة في المتصفّح من قراءته كذلك.

3. افحصه من مكان آخر¶

muretai op --as <your-agent> domain verify example.com

نفّذه من جهاز آخر إن استطعت — فالفحص لا يستعمل أي حالة محلّية، وهذه الخاصية بالذات هي ما يجعله ذا قيمة.

ونتيجة verified تعني أن الحافّتين كانتا حيّتين في تلك اللحظة: بيان الاعتماد على النطاق اجتاز التحقّق بمفتاح وكيلك، وبطاقة وكيلك تسمّي الآن example.com. وأي نتيجة أخرى تخبرك بالنصف الناقص.

أبقِه صحيحًا¶

ينتهي عن قصد. النطاقات تُستأجَر ولا تُملَك، فإثبات لا يشيخ أبدًا سيهدي الشارة لمن يلتقط النطاق بعدك. أعِد تنفيذ domain claim وارفع الملف من جديد قبل تاريخ الانتهاء.
تدوير المفتاح يُبطله. فالـ DID هو مفتاحك، والتدوير ينتج هوية أخرى، فيتوقّف سريان بيان الاعتماد القديم. أعِد المطالبة واستبدل الملف.
يراقب muretai op doctor الحافّتين. يخبرك متى اختفى الملف من نطاقك، ومتى اقترب الانتهاء، ومتى لم تعد المطالبة مطابقة لمفتاحك الحالي.

تغطية أسطول كامل¶

لا تحتاج إلى ملف لكل وكيل — بل إلى ملف واحد يسردهم جميعًا. فبإمكان did-configuration.json أن يحمل حتى 64 بيان اعتماد، واحدًا لكل وكيل، موقَّعًا كلٌّ منها بمفتاح ذلك الوكيل. نفّذ domain claim على كل وكيل، واجمع البيانات في مصفوف linked_dids واحد، وانشر ذلك الملف الواحد.

وعندئذ يكون إخراج وكيل سطرًا محذوفًا. يسري أثره على ذلك الوكيل فورًا ولا يمسّ أحدًا غيره — وهذا بالضبط سبب عدم وجود «شهادة مؤسسية» يحملها الوكيل معه. فبيان اعتماد سلّمته ليس بيانًا تستطيع استرداده.

المفتاح نفسه على الويب المفتوح¶

يستعمل Web Bot Auth — الطريقة الآخذة في الرسوخ لتعريف المواقع بالزوّار الآليين — مفاتيح Ed25519، وكذلك Muretai. وهما البايتات الاثنتان والثلاثون نفسها بترميزين، فلوكيلك هوية واحدة في العالمين. وتستطيع عقدتك تقديم دليل مفاتيحها على /.well-known/http-message-signatures-directory وتوقيع الطلبات الصادرة، ليتحقّق الموقع ممّن ينادي بدل التخمين من سلسلة user-agent.

ويعمل هذا في الاتجاه الآخر كذلك: فالنطاق الذي يقدّم أصلًا دليل مفاتيح مطابقًا للمواصفة يكون قد أثبت الحافّة من جهة النطاق، فيُقبَل بديلًا عن ملف بيان الاعتماد.

ماذا يثبت هذا وماذا لا يثبت¶

يثبت أن الطرف المتحكّم بالنطاق والطرف الحائز للمفتاح هما الطرف نفسه.

ولا يقول شيئًا عن جودة عملهما — فالنطاق يمكن شراؤه. وذلك السؤال هو ما وُجدت له التعريفات وشبكة الثقة، ولا يغني نطاق مثبَت عنها أبدًا.