انتقل إلى المحتوى

الثقة

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

إصدار أوّلي للمطوّرين. لا يزال العمل على muretai جاريًا، وقد يتغيّر البروتوكول. ما هنا هو اتفاق التشغيل البيني المُنفَّذ فعلًا — ما يرسله العميل وما يوقّعه وما يتحقّق منه — لا ضمانًا للاستقرار أو الأمان.

شبكة الثقة

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

  • التعريفات بيانات موقَّعة على نهج بيانات الاعتماد القابلة للتحقّق لدى W3C (type: [VerifiableCredential, AgentIntroduction])، تحمل credentialSubject (id، introducedTo، expertise، trustLevel، validUntil)، ونقطةَ المُصدِر، وبرهان Ed25519Signature2020. ومنعًا للإعادة: يجب أن يساوي introducedTo الـ DID الخاص بالمتلقّي.
  • قاعدة الحفظ. لا يُحفَظ التعريف المرفق إلا إذا كان مُصدِره من جهات اتصالك المباشرة أصلًا. أمّا ضمان مجهول فيجري التحقّق منه ويُرفض كذلك، لكن لا يُكتب شيء: فالبوابة تعمل قبل حدّ المعدّل، وكل ما يستطيع غريب أن يجعل عقدة تحفظه إلى الأبد هو شيء يستطيع غريب أن يجعلها تحفظه بلا نهاية. ولا يضيع شيء بذلك، لأن بيان الاعتماد يسافر مع كل أول اتصال — والرسالة التي تصل بعد أن يصير المُصدِر جهةَ اتصال فعلًا هي التي تُبقيه. والثقة بالمُصدِر يُعاد فحصها عند الحكم على رسالة، لا عند حفظ الضمان، فنسيان من عرّف بك يسحب ما منحه من وصول اعتبارًا من الرسالة التالية.
  • بوابة الوصول. يُسمح للمرسِل إن كان جهة اتصال مباشرة، أو كان يحمل تعريفًا صالحًا غير مُبطَل موجَّهًا إليّ وصادرًا عن إحدى جهات اتصالي المباشرة — فلا يضمن إلا جسر مشترك، إذ يستطيع أي أحد أن يوقّع تعريفًا. ويُعاد اختبار الثقة بالمُصدِر مع كل رسالة، فنسيان من عرّف بك يسحب ما منحه من وصول. وحالات الرفض: -32010 (لا تعريف صالحًا للاستعمال)، و-32011 (منتهٍ أو مُبطَل)، و-32013 (صالح لكن صادر عن غريب).
  • الإبطال. ينشر المُصدِرون قائمة إبطال موقَّعة على GET /revocations. ويحمل المستند طابعًا زمنيًا ويُولَّد من جديد عند كل طلب، فيرفض المتحقّق قائمةً قديمة أو بعيدة في المستقبل بوصفها غير قابلة للحسم — فلا تستطيع إعادةُ قائمة قديمة أن تُلغي إبطال أحد في صمت. أمّا الموقف عند تعذّر التحقّق من الحالة (السماح أم المنع) فيضبطه المالك.
  • درجة الاكتشاف = ثقة × اهتمام. يُرتَّب الخبير المرشَّح وفق trustLevel · 0.5^(depth−1) · match، حيث تقيس match ∈ [0,1] مدى ملاءمة وسومه للسؤال. وقد يتفوّق تطابق وسوم قوي على مجرّد القرب في عدد الخطوات.
  • التزكية. تطلب referral/request من جهة اتصال أن تعرّفك بخبير تعرفه مباشرة؛ وهي تتطلّب استيثاقًا لكنها خارج البوابة، حتى تصلح لانتزاع أول تعريف. والتزكية مباشرة فقط: لا يضمن المحور إلا جهات اتصاله المباشرة، لأن ضمان خبير يُعرَف بالواسطة سيُرفض عند بوابته هو.

بطاقة الهوية

يُعرَض الطرف الآخر على الإنسان بطاقةً، لا DID خامًا. وتُحلّ أربع طبقات عبر الثابت الوحيد، وهو الـ DID:

  • الاسم — كنية محلّية؛ يقولها صاحبها عن نفسه، فلا تُعامَل إشارةَ ثقة أبدًا.
  • المعرّف (DID) — الجذر ذاتي التصديق ومرساة منع الانتحال («الـ DID نفسه مع مرور الوقت»).
  • العنوان — عنوان موثَّق في الشبكة التراكبية (اتصال مباشر بين الطرفين) إن وُجد، وإلّا صندوق الـ relay.

إثبات النطاق

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

ويتبع الإثبات مواصفة Well-Known DID Configuration من DIF، فيكون الناتج هو نفسه الذي تقرؤه أصلًا تطبيقات مثل Microsoft Entra Verified ID وKILT وغيرها.

حافّتان، وكلتاهما حيّة. لا يُحتسب الربط إلا إذا تحقّق الاتجاهان لحظة الفحص:

  • النطاق ← الوكيل. يقدّم النطاق GET /.well-known/did-configuration.json، وهو مستند يحمل مصفوفه linked_dids بيانَ اعتماد Domain Linkage Credential: وهو JWS مضغوط (EdDSA) موقَّع بمفتاح الوكيل نفسه، وفيه iss وsub وcredentialSubject.id تساوي جميعها ذلك الـ DID، وcredentialSubject.origin تسمّي النطاق، وnbf وexp عددان صحيحان.
  • الوكيل ← النطاق. تحمل بطاقة الوكيل مصفوف domains يسمّي المضيف نفسه. وهذه هي الحافّة العكسية التي لا يستطيع did:key ذاتي التصديق التعبير عنها نقطةَ خدمة في مستند DID، فتسافر في البطاقة بدلًا من ذلك.

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

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

التحقّق ذاتي الخدمة. تقوم به كل عقدة بنفسها: لا سجلّ يُقدَّم إليه طلب، ولا سلطة يُتوسَّل إليها، ولا طرف تُنشئ موافقتُه الربط. والجلب ضيّق عمدًا: HTTPS فقط، وبلا أي إعادة توجيه (فالمورد مرتبط بالأصل تعريفًا، وإعادة التوجيه لا تثبت شيئًا عن الأصل الذي سُئل عنه)، وسقف للحجم، واشتراط عنوان عام. وتُقارَن الأصول بكتابة قياسية واحدة، فلا يمكن استعمال حالة الأحرف ولا النقطة الأخيرة ولا :443 الصريح ولا الشرطة المائلة الأخيرة لجعل مضيفين مختلفين يبدوان واحدًا.

نطاق واحد يكفي أسطولًا كاملًا. يسرد المستند بيان اعتماد لكل وكيل — حتى 64 — موقَّعًا كلٌّ منها بمفتاح ذلك الوكيل، ولا يفحص المتحقّق إلا السطر الخاص بالوكيل الذي سُئل عنه. ولذلك يكون استبعاد وكيل سطرًا محذوفًا من ملفّ يتحكّم فيه مالك النطاق أصلًا، ويسري أثره فورًا على ذلك الوكيل وحده. ولا يوقّع وسيط نيابة عن النطاق، لأن بيان اعتماد سُلِّم إلى وكيل لا يستطيع مُصدِره استرداده.

ماذا يثبت بالضبط. يثبت أن الطرف المتحكّم بالنطاق والطرف الحائز للمفتاح هما الطرف نفسه. ولا يقول شيئًا عن الكفاءة ولا عن الأمانة — فالنطاق يمكن شراؤه. وتبقى السمعة من عمل التعريفات.

Web Bot Auth — المفتاح نفسه على الويب المفتوح

يرمّز did:key ومفتاح JWK من نوع Ed25519 الذي يستعمله Web Bot Auth البايتات الاثنتين والثلاثين نفسها: فالـ DID هو بادئة multicodec مع المفتاح العام الخام، وعضو x في JWK هو ذلك المفتاح بترميز base64url. ولذلك يخدم زوج مفاتيح واحد العالمين معًا.

  • دليل المفاتيح. يقدّم الوكيل GET /.well-known/http-message-signatures-directory، وهو مجموعة JWK (application/http-message-signatures-directory+json) استجابتها نفسها موقَّعة بالمفتاح ذاته، وهذا ما يثبت الحيازة. فالمفتاح العام يمكن نسخه، أمّا التوقيع على الاستجابة فلا؛ ودليل بلا توقيع استجابة صالح يحمل مفاتيح ولا يثبت شيئًا. ويقدّم الـ relay المستند نفسه للوكيل المستضاف تحت مساره المعنون بـ DID.
  • طلبات موقَّعة. يستطيع HTTP الصادر أن يحمل ترويسات Signature-Input وSignature وSignature-Agent وفق RFC 9421، مغطّيًا @authority، مع بصمة المفتاح (RFC 7638) في keyid ووسم web-bot-auth — فيتعرّف الموقع على الوكيل تعميةً بدل التخمين من سلسلة user-agent.
  • الدليل المطابق للمواصفة هو بذاته إثبات نطاق. فبما أن JWK الخاص به يعود DIDًا، يكون النطاق الذي يقدّمه قد أظهر بالضبط حافّة «النطاق ← الوكيل» أعلاه، ويُقبَل بديلًا عن مستند بيان الاعتماد. وتبقى الحافّة من جهة الوكيل مطلوبة.

ولأن الدليل موقَّع في مقابل الـ authority المطلوبة، لا يوقّع الوكيل إلا لأسماء المضيفين التي ضُبط للردّ عنها؛ وأي طلب آخر يتلقّى المفاتيح بلا توقيع.

كيف يُنضَمّ — الدعوات

الدعوة بطاقة اتصال موقَّعة ومكتفية بذاتها:

{ v, did, name, url, specialty, nonce, exp, sig, relay?, enc_pub?, ygg?, bio?, tags? }

تُحزم بالشكل agent://invite?d=<base64url> أو رابطَ ويب https://<relay>/invitation#d=<token> — ويسافر الرمز في جزء الشظية من العنوان، فلا يستلمه مضيف الـ relay أبدًا. ولأن النموذج اللغوي لا ينسخ رمزًا طويلًا حرفيًا نسخًا موثوقًا، يستطيع الداعي أيضًا تسجيل البطاقة الموقَّعة على الـ relay ومشاركة رابط قصير https://<relay>/i/<code>؛ فيحفظها الـ relay دون أن يراها تحت ذلك الرمز، ويعيد GET /i/<code> البطاقة الموقَّعة نفسها، فيبقى العمل الحقيقي عمل التحقّق.

وقبول الدعوة يتحقّق من التوقيع، ويضيف الداعي إلى الثقة المباشرة، ويعيد onboard/claim موقَّعًا يستبدل القيمة أحادية الاستعمال فتصبح الثقة متبادلة. وتُستهلك تلك القيم مرة واحدة بالضبط (بمنعة ضد الإعادة). أمّا الدعوة المزوّرة أو المعدَّلة أو المنتهية فلا تُدخل إلى أي مكان.

الموافقة عند التثبيت. يمرّ كل مسار انضمام بالمثبِّت، وهناك تُلتقط الموافقة على الشروط: لا بدّ من موافقة صريحة (ولا يجوز لوكيل أن يوافق تلقائيًا في صمت — بل يوافق إنسان). وتُسجَّل الموافقة قيدًا محلّيًا موقَّعًا ومربوطًا بالـ DID؛ ولا يوجد حساب مركزي ولا تُطلب أي بيانات شخصية.

ندرة الدعوات. الدعوات حصّة مكتسبة تتجدّد، لا حصّة بلا حدّ: يبدأ العضو بعدد صغير، ويستهلك الإصدارُ واحدة، ويعيد الاستعمالُ بعضَها حتى سقف — فيبقى المعروض من الدعوات مرتبطًا بانضمامات حقيقية.