---
title: "الهوية اللامركزية (DID)"
description: "دليل عملي للمعرّفات اللامركزية وبيانات الاعتماد القابلة للتحقق: ما الذي تثبته، وكيف يعمل الإصدار والعرض، وأين تبقى مخاطر الثقة والخصوصية والاسترداد."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# الهوية اللامركزية (DID)

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

الهوية اللامركزية بنية تمكّن صاحب الهوية من استخدام معرّفات وبيانات اعتماد محمية بالتشفير عبر خدمات متعددة من دون جعل حساب منصة واحدة المصدر الشامل للهوية. تشمل مكوناتها المعتادة المعرّفات اللامركزية (DID)، وبيانات الاعتماد القابلة للتحقق (VC)، وبرمجيات الحامل مثل المحفظة، والقواعد التي تحدد جهات الإصدار والأدلة ومستويات الضمان المقبولة لدى جهة التحقق.

معرّف DID هو URI مثل `did:example:123`. تحدد طريقة DID كيفية إنشاء المعرّف وحله وتحديثه وتعطيله. قد يعيد الحل مستند DID يحتوي طرق تحقق وعلاقات مثل `authentication` أو `assertionMethod` ونقاط خدمة اختيارية. يثبت التحكم في المفتاح المقابل التحكم في DID وفق تلك الطريقة؛ لكنه لا يثبت وحده الاسم القانوني أو العمر أو التفرد أو العمل أو ملكية حساب خارجي.

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

لذلك لا تعني «لامركزية» انعدام الثقة أو إخفاء الهوية أو وجوب البلوكشين أو غياب الوسطاء. بل تعني إمكان فصل المعرّفات وبيانات الاعتماد والسجلات والمحافظ وسياسات التحقق حتى لا يراقب مزود دخول واحد كل العلاقات ويتحكم فيها. تعتمد اللامركزية الفعلية على جهات الإصدار ومشغلي طرق DID وخدمات الحالة وموردي المحافظ ومسؤولي الاسترداد ومفاتيح الحوكمة وسياسات التحقق.

<a id="mechanism"></a>

## آلية العمل

1. **تحديد الادعاء وإطار الثقة.** يجب تحديد صاحب الهوية والسمات المطلوبة وجهات الإصدار المقبولة وإجراءات الإثبات ومستوى الضمان وسياسة الاحتفاظ والاختصاص ومسار الاعتراض. لا يقرر التنسيق التشفيري إن كانت جامعة أو حكومة أو جهة عمل أو جماعة سلطة مناسبة.
2. **إنشاء المعرّفات والمفاتيح أو الحصول عليها.** يمكن لجهة الإصدار والحامل استخدام DID أو عناوين HTTPS URL أو غيرها. عند استخدام DID تحدد الطريقة السجل ودورة الحياة. يحمي المتحكم المفتاح الخاص، ولا يكشف المستند المحلول إلا مواد التحقق والنقاط اللازمة.
3. **إثبات صاحب الهوية وربطه.** تفحص جهة الإصدار الأدلة وفق السياسة ثم تربط الادعاءات بصاحب بيانات الاعتماد. قد يشير الربط إلى مفتاح يتحكم فيه الحامل أو حساب أو معرّف آخر. يجب التفريق بين دليل عن شخص ودليل أن المقدّم الحالي يتحكم في مفتاح.
4. **إصدار بيانات الاعتماد.** تنشئ جهة الإصدار الادعاءات وتواريخ الصلاحية ومعلومات المخطط أو النوع ومرجع الحالة ثم تحميها بإثبات مدعوم. في Data Integrity تحدد الحقول `cryptosuite` و`verificationMethod` و`proofPurpose` و`proofValue` طريقة التحقق.
5. **التخزين والاختيار.** يحتفظ الحامل ببيانات الاعتماد في محفظة محلية أو مستضافة. ينبغي أن تشرح المحفظة الطلب، وتكشف البيانات الضرورية فقط إذا أتاح التنسيق ذلك، وألا تعيد استخدام معرّف ثابت بصمت في سياقات غير مترابطة.
6. **العرض مع الحداثة والربط بالجمهور.** ترسل جهة التحقق هويتها والغرض وقيمة nonce أو challenge والانتهاء. يعيد الحامل بيانات الاعتماد أو عرضاً مشتقاً مرتبطاً بالطلب. يمنع فحص النطاق وchallenge إعادة العرض لجهة تحقق أو جلسة أخرى.
7. **التحقق من التشفير والسياسة.** تُحل مواد جهة الإصدار من مصدر موثّق؛ وتُفحص الحزمة والغرض وchallenge والنطاق والتواريخ والمخطط والحالة؛ ثم تطبق قواعد العمل. النتيجة `verified: true` مدخل للتفويض وليست أمراً بمنح الوصول.
8. **تشغيل دورة الحياة.** يجب تدوير المفاتيح المخترقة وتعليق بيانات الاعتماد أو إلغاؤها وتحديث الحالة وتوفير الاسترداد والاعتراض وحفظ أدلة التدقيق ونشر خطط الانتقال أو الإغلاق. يحتاج التحقق التاريخي إلى قواعد للمفاتيح والمستندات القديمة ووقت العرض.

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

DID وVC مستقلان. يمكن لـ VC استخدام معرّف جهة إصدار ليس DID، ويمكن استخدام DID بلا VC. كما يمكن لطريقة DID استخدام بلوكشين أو قاعدة بيانات موزعة أو نطاق ويب أو تبادل نظير إلى نظير. يجب تقييم أمن الطريقة وحوكمتها مباشرة لا استنتاجهما من البادئة `did:`.

<a id="example"></a>

## مثال عملي

لنفترض أن خدمة يجب أن تؤكد أن عمر العميل 18 عاماً على الأقل من دون جمع تاريخ الميلاد. تتحقق جهة معتمدة من العميل وتصدر بيانات اعتماد عمر إلى المحفظة. قد تتضمن تاريخ الميلاد أو ادعاء `ageOver18` فقط؛ ولكل خيار خصائص إفصاح وإعادة استخدام مختلفة.

عند التسجيل تطلب الخدمة عرضاً لعمر فوق 18 خاصاً بـ `merchant.example`، مع challenge قيمته `n-7f3a` ونافذة صلاحية 5 دقائق. تعرض المحفظة الطلب، وإذا دعمت بيانات الاعتماد وحزمة الإثبات ذلك تشتق عرضاً يكشف الشرط المطلوب فقط. تفحص الخدمة طريقة الجهة والإثبات وchallenge والنطاق والنافذة والحالة قبل تسجيل أقل نتيجة لازمة للتدقيق.

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

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

<a id="risks"></a>

## المخاطر والضوابط

- **ادعاءات خاطئة أو مفرطة:** يحفظ التوقيع الصحيح ما قالته جهة الإصدار لكنه لا يجعله دقيقاً. يجب تحديد الأدلة والمسؤولية والضمان والتدقيق والانتهاء والتصحيح.
- **ضعف ربط الحامل:** قد يستخدم شخص آخر نسخة إذا لم يثبت العرض التحكم في المفتاح أو المصادق المقصود. اربط إثبات الحيازة بجهة التحقق وchallenge والغرض والجلسة عند الحاجة.
- **اختراق المفتاح والمحفظة:** قد تكشف البرمجيات الخبيثة والتصيد والاستيلاء على محفظة سحابية والنسخ الضعيفة البيانات والمفاتيح. استخدم مصادقة مقاومة للتصيد وحماية عتادية مناسبة والإبلاغ واسترداداً محدوداً.
- **مركزية الاسترداد:** قد يصبح مسؤول واحد المتحكم الحقيقي في الهوية. وثّق من يستبدل المفاتيح والأدلة المطلوبة وكشف الإساءة وكيفية الاعتراض أو الانتقال.
- **الربط:** قد يربط تكرار DID أو الطريقة أو نمط التوقيع أو نقطة الخدمة أو مسار الحالة النشاط بين الخدمات. استخدم معرّفات ثنائية ومفاتيح أو إثباتات مفصولة بالنطاق وحالة تحمي الخصوصية واختبار البيانات الوصفية.
- **البيانات الشخصية العامة:** قد تُفهرس مستندات DID وسجلات الدفتر علناً ويصعب حذفها. أبق الأسماء وأرقام الوثائق والقياسات الحيوية والادعاءات الشخصية خارج المستندات العامة والسجلات الثابتة.
- **خصوصية الحالة وتوافرها:** يكشف الاتصال بجهة الإصدار كل مرة موضع الاستخدام، ويمنع العطل المستخدمين الصحيحين. فضّل حالة تحمي الخصوصية وقابلة للتخزين المؤقت مع حد للحداثة وتحديثات موثقة وسلوك فشل محدد.
- **إساءة الإلغاء:** يمكن لجهة إصدار أو مسؤول حجب الحامل بالتعليق أو تغيير الحالة. قيّد السلطة وسجّل التغييرات وأظهر السبب والاعتراض وادعم الاستبدال أو جهة بديلة.
- **مخاطر الحل والطريقة:** قد يعيد المحلل مستنداً قديماً أو خبيثاً، وقد تعتمد الطريقة على بنية مركزية. وثّق النتائج وقيّم النهائية وصلاحية التحديث والتوافر والحوكمة والإصدارات.
- **اختلاف الدلالة:** قد تفسر منظومتان الحقول نفسها بصورة مختلفة للادعاء أو الوحدة أو الاختصاص أو الضمان. استخدم مخططات ومفردات مستقرة وتحقق من السياق والنوع وعيّن إصداراً لدلالة السياسة.
- **إعادة التشغيل والتباس المتحقق:** يمكن إعادة عرض غير مرتبط بـ nonce والجمهور والنطاق والإجراء والانتهاء أو تحويله. تحقق من كل روابط البروتوكول.
- **الإفصاح المفرط:** حتى مع الإفصاح الانتقائي قد تطلب جهة التحقق بيانات الاعتماد كاملة. طبّق تقليل البيانات في السياسة والواجهة وسجّل الغرض ولا تجعل الحقول الاختيارية إلزامية بالعادة.
- **الاحتجاز داخل المنظومة:** تقلل المحافظ والإثباتات والسجلات والاسترداد المملوكة قابلية النقل. اختبر التوافق والتصدير وتعدد المحافظ والمرونة التشفيرية والانتقال قبل النشر.
- **الاستيلاء على الحوكمة:** لا يضمن تعدد التوقيع أو السجل تحكماً واسعاً إذا اختار مورد واحد الجهات والتحديثات والمخططات والحالة. ارسم السلطة لكل مكون وانشر ضوابط التغيير.

<a id="misconceptions"></a>

## مفاهيم خاطئة شائعة

- **«يثبت DID من هو الشخص».** يعرّف DID صاحباً وقد يكشف طرق تحقق؛ أما السمات فتحتاج ادعاءات وأدلة وقرارات ثقة إضافية.
- **«بيانات الاعتماد الصحيحة تجعل الادعاء صحيحاً».** يثبت التحقق وجود الإثبات المتوقع وعدم تغيير البيانات، لا صحة تحقيق جهة الإصدار الأصلي.
- **«الحامل دائماً هو صاحب بيانات الاعتماد».** قد تختلف الأدوار؛ لذا يلزم ربط صريح بين الصاحب والمقدّم عندما تتطلب الحالة.
- **«يجب وضع كل شيء على السلسلة».** يفاقم التخزين العام الثابت مخاطر الخصوصية والربط والحذف والحوكمة. تحتفظ أنظمة كثيرة بالبيانات خارج السلسلة.
- **«يضمن الإفصاح الانتقائي إخفاء الهوية».** يمكن للسمات والمعرّفات الثابتة وبصمات الإثبات وطلبات الحالة والتوقيت وعنوان IP وسجلات الجهة ربط العروض.
- **«اللامركزية تعني عدم وجود جهة إصدار أو مسؤول موثوق».** توزع الثقة وتصبح صريحة ولا تختفي. يظل الإصدار والإثبات والمحفظة والاسترداد والحالة والقبول خاضعاً للحوكمة.
- **«DID واحد يساوي إنساناً واحداً».** يمكن لشخص التحكم في عدة DID، ويمكن لـ DID تعريف مؤسسة أو جهاز أو بيانات أو دور أو صاحب آخر. يحتاج التفرد والإنسانية إلى آليات منفصلة.
- **«يكفي توقيع المحفظة للمصادقة».** يثبت التحكم في مفتاح ضمن شروط محددة. ما زالت الخدمة تحتاج مقاومة التصيد والحداثة وربط الجمهور والتفويض واسترداد الحساب.

<a id="related"></a>

## موضوعات ذات صلة

- [المجمّع التشفيري](/crypto/cryptographic-accumulator/)
- [إثبات الإنسانية](/crypto/proof-of-personhood/)
- [هجوم سيبيل](/crypto/sybil-attack/)
- [توقيع المحفظة](/crypto/wallet-signature/)
- [إثبات المعرفة الصفرية](/crypto/zero-knowledge-proof/)

<a id="sources"></a>

## المصادر

- [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-1.0/) - W3C (تاريخ الاطلاع: 2026-08-20)
- [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - W3C (تاريخ الاطلاع: 2026-08-20)
- [Verifiable Credential Data Integrity 1.0](https://www.w3.org/TR/vc-data-integrity/) - W3C (تاريخ الاطلاع: 2026-08-20)
- [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) - W3C (تاريخ الاطلاع: 2026-08-20)
- [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) - NIST (تاريخ الاطلاع: 2026-08-20)

Source: https://wiki.fcontext.com/ar/crypto/decentralized-identity/index.mdx