فهم معيار المعرفات اللامركزية (DIDs) من W3C (AR)

تحدد مواصفات المعرفات اللامركزية (DIDs) من W3C بناء جملة URI، ونموذج بيانات مشترك، ومستندات DID، وخصائص أساسية، وتمثيلات، ومتطلبات الأساليب، وواجهات مجردة للحل وإلغاء الرجوع إلى DID URL. أصبح DID Core 1.0 توصية من W3C في 19 يوليو 2022. تم نشر DID Core 1.1 كلقطة توصية مرشحة في 5 مارس 2026؛ وهو عمل أحدث في مرحلة معايير مختلفة.

لا يتطلب DID Core سلسلة كتل (بلوك تشين)، ولا يثبت الهوية القانونية للشخص، ولا يخزن بيانات الاعتماد داخل كل مستند DID، ولا يجعل كل نقطة نهاية محلولة جديرة بالثقة. إنه يوحد بنية المعرف والمستند. تحدد طريقة DID منفصلة كيفية إنشاء DID معين وقراءته وتحديثه وإلغاء تنشيطه على البنية التحتية المختارة.

النقاط الرئيسية

• DID هو URI، وليس بيانات اعتماد. شكله العام هو did:<method-name>:<method-specific-id>.
• الجهة الفاعلة ووحدة التحكم هما دوران مختلفان. الجهة الفاعلة هي ما يحدده DID؛ ووحدة التحكم مصرح لها من قبل الطريقة لتغيير مستند DID.
• تتطلب المفاتيح أغراضًا صريحة. تصبح طريقة التحقق قابلة للاستخدام للمصادقة، أو التأكيد، أو اتفاقية المفتاح، أو استدعاء القدرة، أو التفويض فقط من خلال علاقة التحقق المقابلة.
• توفر الطريقة القواعد التشغيلية. DID Core محايد تقنيًا؛ وتحدد الطريقة تفاعل السجل، والترخيص، والتحديث، وإلغاء التنشيط، والحل الخاص بالطريقة.
• الحل لا يخلق الثقة بمفرده. يجب على المنفذين مصادقة نتائج الطريقة، وفرض غرض الإثبات، وإدارة المفاتيح والسجل، وحماية الخصوصية، وتطبيق سياسة التطبيق.

ما هو المعرف اللامركزي؟

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

يمكن لـ DID تحديد:

• شخص؛
• منظمة أو مجموعة؛
• جهاز أو كائن مادي؛
• مورد رقمي؛
• نموذج بيانات؛
• مفهوم مجرد.

الكيان المحدد هو الجهة الفاعلة لـ DID. لا يكشف السلسلة وحدها عن نوع الجهة الفاعلة.

بناء جملة DID

بناء الجملة العام هو:

did:<method-name>:<method-specific-id>

على سبيل المثال:

did:example:123456789abcdefghi

did هو مخطط URI. example هو اسم طريقة DID. السلسلة المتبقية هي المعرف الخاص بالطريقة. يحدد مواصفات الطريقة معنى هذه القيمة وكيفية معالجتها بواسطة البرامج.

DID الذي يبدو صالحًا ليس بالضرورة قابلاً للاستخدام. يجب أن توجد الطريقة ويجب أن يدعمها المحلل.

عناوين URL لـ DID: المسارات، والاستعلامات، والأجزاء

يبدأ عنوان URL لـ DID بـ DID ويمكن إضافة مسار أو استعلام أو جزء:

did:example:123456789abcdefghi/path?service=messages#key-1

يمكن لهذه المكونات تحديد أو المساعدة في اختيار:

• طريقة تحقق داخل مستند DID؛
• إدخال خدمة؛
• جزء آخر من مستند DID؛
• مورد يتم الوصول إليه من خلال خدمة؛
• إصدار أو خيار محدد بالطريقة.

يحدد الجزء #key-1 عادة طريقة تحقق. ولا يعني أن المفتاح الخاص موجود في المستند. تنشر مستندات DID مواد تحقق عامة أو مراجع؛ ويجب أن تظل المواد السرية محمية في مكان آخر.

بنية DID

المفاهيم الرئيسية مترابطة ولكنها ليست قابلة للتبديل:

المفهوم	الدور
DID	معرف فريد عالميًا يلتزم ببناء جملة DID
الجهة الفاعلة لـ DID	شخص، منظمة، شيء، مورد، أو مفهوم محدد
وحدة تحكم DID	كيان مصرح له بموجب طريقة DID لتغيير مستند DID
مستند DID	البيانات المرتبطة بالجهة الفاعلة، بما في ذلك طرق التحقق والخدمات المسموح بها
طريقة DID	مواصفات منفصلة لبناء الجملة والعمليات الخاصة بالطريقة
سجل البيانات القابلة للتحقق	البنية التحتية التي تستخدمها الطريقة لإنشاء، قراءة، تحديث، أو إلغاء تنشيط حالة DID
محلل DID	برنامج أو جهاز يقوم بحل DID للطرق المدعومة
مُحلّل DID URL	برنامج أو جهاز يحصل على مورد محدد بواسطة DID URL

الجهة الفاعلة مقابل وحدة التحكم

يمكن أن تكون الجهة الفاعلة ووحدة التحكم نفس الكيان، ولكن ليس بالضرورة. يمكن للوالد التحكم في DID لطفل، ويمكن للمنظمة التحكم في DID لجهاز، أو يمكن لعدة أمناء التحكم في ترتيب استرداد.

تحدد controller ذات المستوى الأعلى DID واحدًا أو أكثر من وحدات التحكم في DID. تحدد controller المطلوبة لطريقة التحقق من يتحكم في تلك الطريقة؛ وهي ليست تلقائيًا وحدة التحكم في DID ذات المستوى الأعلى. يمكن أن يؤدي الخلط بينهما إلى منح سلطة غير مقصودة.

ما هو مستند DID؟

مستند DID هو البيانات المرتبطة بالجهة الفاعلة لـ DID بموجب نموذج بيانات DID Core. جذر id هو DID. يمكن للخصائص الأساسية الاختيارية وصف وحدات التحكم، والمعرفات البديلة، وطرق التحقق، وعلاقات التحقق، والخدمات.

يستخدم هذا المثال المبسط مواد عامة من مساحة أمثلة المواصفات:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example محجوز للأمثلة؛ يجب أن تستخدم أنظمة الإنتاج طريقة فعلية ومتطلبات مجموعة طرق التحقق الحالية. JSON أعلاه صالح JSON عمدًا. تحتوي العديد من الأمثلة المطبوعة داخل المواصفات الفنية على تعليقات أو علامات حذف لسهولة القراءة ويجب عدم نسخها مباشرة إلى محلل.

الخصائص الأساسية

• id: DID للجهة الفاعلة؛ مطلوب في جذر المستند.
• controller: DID واحد أو أكثر مصرح له بإجراء تغييرات بموجب الطريقة.
• alsoKnownAs: عناوين URI أخرى تؤكد أنها تحدد نفس الجهة الفاعلة.
• verificationMethod: آليات التحقق العامة التي يمكن الرجوع إليها بواسطة علاقات صريحة.
• authentication: الطرق المصرح بها للمصادقة كجهة فاعلة.
• assertionMethod: الطرق المصرح لها بالتعبير عن المطالبات، مثل إصدار بيانات الاعتماد.
• keyAgreement: الطرق المخصصة لاشتقاق مواد سرية مشتركة.
• capabilityInvocation: الطرق المصرح لها باستدعاء القدرات.
• capabilityDelegation: الطرق المصرح لها بتفويض القدرات.
• service: نقاط النهاية أو آليات التفاعل المرتبطة بالجهة الفاعلة.

alsoKnownAs هو تأكيد، وليس دليلًا تشفيريًا على أن معرفين متكافئان. يجب على التطبيقات التحقق بشكل مستقل من العلاقة المطلوبة بواسطة نموذج الثقة الخاص بها.

نموذج البيانات والتمثيلات

يحدد DID Core نموذج بيانات مجردًا وقواعد لإنتاج واستهلاك التمثيلات. نموذج البيانات ليس مطابقًا لتسلسل JSON واحد.

متطلبات التمثيل خاصة بالإصدار:

• توصية DID Core 1.0 لعام 2022 تحدد application/did+json وapplication/did+ld+json. يبدأ تمثيل JSON-LD الخاص بها بالسياق الأساسي https://www.w3.org/ns/did/v1.
• توصية DID Core 1.1 Candidate Recommendation توحد نوع الوسائط الأساسي إلى application/did. يبدأ تمثيل JSON-LD الخاص بها بـ https://www.w3.org/ns/did/v1.1.

لا تخلط نوع الوسائط أو السياق الأساسي من إصدار واحد مع ادعاءات التوافق مع الآخر. قم بتثبيت إصدار المواصفات الذي ينفذه المنتجون والمستهلكون.

يجب على المنفذين التفاوض والتحقق من التمثيل بشكل صريح. توقيع بايتات JSON المتسلسلة العشوائية بدون تحديد توحيد وآلية تأمين ليس مكافئًا لمعالجة نموذج بيانات DID بشكل صحيح.

طرق التحقق وعلاقات التحقق

تصف طريقة التحقق كيفية التحقق من الإثبات. وتتطلب:

• id معبر عنه كعنوان DID URL؛
• type؛
• controller؛
• مواد التحقق المناسبة لهذا النوع.

يمكن تمثيل المواد العامة من خلال خاصية محددة مثل publicKeyJwk أو شكل آخر مسموح به بواسطة مجموعة طرق التحقق. يجب ألا يتضمن JWK في مستند DID مواد المفتاح الخاص. يجب عدم تكرار نفس مواد التحقق في خصائص مواد متعددة ضمن طريقة واحدة.

تحديد طريقة تحقق لا يصرح بها لكل غرض. يأتي التصريح من علاقات التحقق الخمس الصريحة.

العلاقة	الغرض المقصود من الإثبات
authentication	المصادقة كجهة فاعلة لـ DID من خلال تحدي-استجابة أو آلية أخرى مقبولة
assertionMethod	التعبير عن المطالبات، بما في ذلك توقيع بيانات اعتماد قابلة للتحقق حيث تستخدمها آلية التأمين المختارة
keyAgreement	إنشاء مواد تشفير مشتركة، غالبًا للتشفير
capabilityInvocation	استدعاء قدرة كائن
capabilityDelegation	تفويض قدرة كائن

يجب على المحقق التحقق من العلاقة المطلوبة للإثبات. المفتاح المدرج تحت authentication فقط لا يُصرح به تلقائيًا لتأكيدات بيانات الاعتماد أو اتفاقية المفتاح.

يمكن للعلاقات تضمين طريقة تحقق كاملة أو الرجوع إلى واحدة بواسطة DID URL. المراجع تحسن إعادة الاستخدام ولكنها تتطلب إلغاء الرجوع الصحيح ومقارنة المعرف الدقيقة.

الخدمات ونقاط نهاية الخدمة

يمكن لخاصية service الاختيارية الإعلان عن طرق للتواصل مع الجهة الفاعلة لـ DID أو التفاعل معها. كل إدخال خدمة له:

• id فريد؛
• type؛
• serviceEndpoint.

قد تكون نقطة النهاية URI أو بنية أخرى مسموح بها. تعريفات الخدمة قابلة للتوسيع، لذلك يجب أن تفهم التطبيقات النوع المختار.

نشر نقطة نهاية لا يثبت أن خادمها، أو مشغلها، أو نقلها، أو محتواها، أو وجهتها جديرة بالثقة.

يجب على التطبيق مصادقة حالة DID المحلولة من خلال الطريقة، والتحقق من صحة نوع الخدمة، وتطبيق عناصر التحكم في أمان URL والشبكة، واستخدام بروتوكول تطبيق له خصائص أمان خاصة به.

يمكن أن تخلق نقاط نهاية الخدمة العامة أيضًا ارتباطًا. إعادة استخدام نقطة نهاية واحدة عبر DIDs الزوجية يمكن أن يقوض فائدة الخصوصية للمعرفات المنفصلة.

ما الذي تحدده طريقة DID

يوفر DID Core البنية المشتركة. تحدد طريقة DID المتوافقة القواعد الخاصة بالطريقة اللازمة لتنفيذها، بما في ذلك:

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

يمكن أن يكون سجل البيانات القابلة للتحقق دفتر أستاذ موزع، أو نظام ملفات لامركزي، أو شبكة نظير إلى نظير، أو قاعدة بيانات، أو نظام آخر. يجب تقييم البنية على أساس الحوكمة، والتوافر، والترخيص، والخصوصية، والتكلفة، والسجل، ومقاومة الهجوم بدلاً من كلمة “لامركزي”.

معايير اختيار الطريقة

قبل اختيار طريقة، اختبر:

• نضج المواصفات والحوكمة؛
• قابلية التشغيل البيني للمحلل والمكتبة؛
• ترخيص التحديث وإلغاء التنشيط؛
• دورة المفاتيح والاسترداد؛
• دعم الحالة التاريخية؛
• الخصوصية وتسرب البيانات الوصفية؛
• توفر السجل ومخاطر الرقابة؛
• تكاليف المعاملات أو التشغيل؛
• المرونة التشفيرية؛
• الترحيل وفشل الطريقة.

عادة ما يعني تغيير الطرق إدخال معرف جديد ومسار ترحيل موثوق به.

حل DID مقابل إلغاء الرجوع إلى DID URL

يأخذ حل DID DID وخيارات الحل ويعيد:

1. بيانات وصفية لحل DID؛
2. مستند DID، أو تدفق مستند، أو لا يوجد مستند؛
3. بيانات وصفية لمستند DID.

يستخدم المحلل عملية “القراءة” المحددة بواسطة الطريقة. يحدد DID Core واجهات مجردة ومفاهيم نتائج مشتركة؛ وتبقى الاتصالات والمصادقة الخاصة بالطريقة مع الطريقة.

يأخذ إلغاء الرجوع إلى DID URL DID URL كاملاً ويعيد:

1. بيانات وصفية لإلغاء الرجوع؛
2. المورد المحدد، إذا كان متاحًا؛
3. بيانات وصفية للمحتوى.

قد يقوم إلغاء الرجوع أولاً بحل DID الأساسي ثم اختيار جزء، أو خدمة، أو مورد خارجي. إنه ليس مرادفًا للحل.

تطور مواصفات W3C DID Resolution المنفصلة خوارزميات حل وإلغاء الرجوع مفصلة. أحدث نشر لها هو مسودة عمل W3C بتاريخ 24 يوليو 2026، ويتم وضع علامة على إلغاء الرجوع إلى DID URL كميزة معرضة للخطر. يظل عملًا في مسار المعايير بدلاً من جزء من توصية DID Core 1.0 لعام 2022، لذا قم بتثبيت المسودة قبل المطالبة بالتوافق.

ثقة المحلل والتخزين المؤقت

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

• التحقق من نتيجة الطريقة؛
• نقل ومصادقة المحلل؛
• حداثة التخزين المؤقت وإلغاء الصلاحية؛
• خيارات الإصدار والوقت؛
• معالجة الأخطاء وسلوك التخفيض؛
• تسرب الخصوصية من خلال عمليات البحث؛
• السلوك أثناء فشل السجل أو الشبكة.

DIDs وبيانات الاعتماد القابلة للتحقق

DIDs وبيانات الاعتماد القابلة للتحقق هي مواصفات مكملة، وليست نفس الكائن.

قد يحدد DID أساسي:

• جهة إصدار بيانات اعتماد؛
• جهة فاعلة لبيانات اعتماد؛
• حامل.

يتم تحديد طريقة التحقق المستخدمة بواسطة آلية تأمين بدلاً من ذلك بواسطة DID URL، وعادة ما يكون DID متبوعًا بجزء مثل #key-1.

يحدد نموذج بيانات بيانات الاعتماد القابلة للتحقق من W3C 2.0 بيانات الاعتماد، والعروض التقديمية، والجهة المصدرة، والحامل، والجهة الفاعلة، والصلاحية، والحالة، والمخططات، وآليات التأمين. ولا يتطلب أن يكون كل معرف DID.

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

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

تتعلق هذه الفحوصات بآلية التأمين، ونظام الحالة، وإطار الثقة، وربط العرض التقديمي، وسياسة الطرف المعتمد.

اعتبارات الخصوصية والأمان

تجنب البيانات الشخصية في المستندات العامة

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

منع الارتباط

يمكن لـ DIDs الزوجية أو الخاصة بالسياق أن تقلل الارتباط فقط إذا تم فصل البيانات الأخرى أيضًا. يمكن للمفاتيح المعاد استخدامها، ونقاط نهاية الخدمة، ومعرفات الشبكة، وسمات بيانات الاعتماد، والتوقيت، ونشاط السجل ربط DIDs التي يفترض أنها منفصلة.

تدوير المفاتيح واستعادتها

خطط للتسوية قبل الإطلاق. حدد ترخيص التحديث، ووحدات التحكم في الاسترداد، وقواعد العتبة، والدوران، ومعالجة المفاتيح القديمة، وإلغاء التنشيط. تحتاج سلطة الاسترداد إلى الفصل والتدقيق.

التحقق من غرض الإثبات

تحقق ليس فقط من صحة التوقيع، ولكن أيضًا من أن طريقة التحقق مصرح بها للعلاقة المطلوبة في الوقت المناسب. منع الاستبدال بين استخدامات المصادقة، والتأكيد، والاتفاقية، والقدرة.

تعامل مع السجل بعناية

قد لا يحتوي مستند DID الحالي على مفتاح قديم. قد يتطلب التحقق من إثبات تاريخي إصدارًا تاريخيًا مدعومًا بالطريقة وأدلة موثوقة لوقت الإثبات. "المفتاح غير موجود الآن" و "الإثبات لم يكن صالحًا أبدًا" ليسا استنتاجات متكافئة.

أخطاء شائعة في تنفيذ DID

تسمية DID Core مواصفات سلسلة كتل

DID Core محايد تقنيًا. سلاسل الكتل هي بنية سجل محتملة واحدة.

معاملة DID كدليل على الهوية القانونية

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

استخدام أي مفتاح مدرج لأي غرض

فرض علاقة التحقق الصريحة وغرض الإثبات.

الثقة بنقاط نهاية الخدمة تلقائيًا

تحقق من صحة حالة الطريقة وطبق أمان طبقة التطبيق، والنقل، وURL، والمحتوى.

افتراض أن جميع DIDs خاصة أو مجهولة

يمكن أن يكشف نشاط السجل، والحل، والمواد المعاد استخدامها، والخدمات عن ارتباط دائم.

قائمة مراجعة التنفيذ لـ DID

قبل الإنتاج، تأكد مما يلي:

• تم تثبيت إصدار DID Core المحدد ومواصفات طريقة DID؛
• يستخدم تحليل المعرف وعنوان DID URL معالجة URI المتوافقة مع المعايير؛
• التمثيلات المقبولة وأنواع الوسائط واضحة؛
• يفرض كل إثبات علاقة التحقق المقصودة؛
• يتم مصادقة نتائج الطريقة بدلاً من الثقة بها من أي محلل؛
• تم اختبار التخزين المؤقت، والإصدار، والتحقق التاريخي، وإلغاء التنشيط؛
• تتوفر إجراءات مجربة للتحديث، والتدوير، والاختراق، والاسترداد، والترحيل؛
• لا تحتوي المستندات العامة على بيانات شخصية أو مرتبطة غير ضرورية؛
• تخضع نقاط نهاية الخدمة لمراجعة أمنية منفصلة على مستوى التطبيق؛
• تظل فحوصات الثقة، والحالة، والمخطط، والعرض التقديمي لبيانات الاعتماد القابلة للتحقق منفصلة.

حيث تلتقي DIDs بالتحقق من الهوية

يمكن لـ DIDs تحديد الجهات الفاعلة ومواد التحقق، لكنها لا تقوم بتدقيق الهوية. لا يزال نظام الهوية القابل لإعادة الاستخدام يحتاج إلى أدلة موثوقة وقرار محكوم قبل إصدار أو قبول المطالبات. يمكن لـ التحقق من الهوية من Didit توفير أدلة الهوية لمثل هذا القرار، بينما يدعم معرفة عميلك (KYC) القابل لإعادة الاستخدام إعادة استخدام التحقق السابق عبر الخدمات المشاركة وهو مدرج مجانًا.

لا يعني التجاور بين المنتجات أن كل تحقق من Didit هو DID أو أن حل DID يحل محل KYC. تتوفر أسعار الوحدات الحالية على صفحة الأسعار. يجب أن تحافظ البنية على التحكم في المعرف، وأدلة الهوية، وإصدار بيانات الاعتماد، والعرض التقديمي، وسياسة الطرف المعتمد كحدود ثقة منفصلة.

الأسئلة الشائعة

ما الذي تحدده مواصفات W3C DID؟

تحدد بناء جملة DID وDID URL، ونموذج بيانات مشترك، وخصائص مستند DID الأساسية، والتمثيلات، ومتطلبات الأساليب، وواجهات حل وإلغاء الرجوع المجردة.

هل يستخدم كل DID سلسلة كتل؟

لا. يمكن لطريقة DID استخدام دفتر أستاذ، أو قاعدة بيانات، أو نظام نظير إلى نظير، أو نظام ملفات لامركزي، أو بنية سجل أخرى.

ما الفرق بين DID ومستند DID؟

DID هو المعرف. مستند DID هو بيانات مرتبطة يمكن أن تصف وحدات التحكم، وطرق التحقق وأغراضها، والخدمات، والخصائص الأخرى المحددة.

ما الفرق بين الحل وإلغاء الرجوع؟

يحصل الحل على مستند DID وبيانات وصفية لـ DID. يحصل إلغاء الرجوع على المورد المحدد بواسطة DID URL كامل، ربما بعد حل DID الأساسي الخاص به.

هل DID هو نفسه بيانات الاعتماد القابلة للتحقق؟

لا. DID هو معرف. بيانات الاعتماد القابلة للتحقق هي مجموعة من المطالبات المقاومة للتلاعب والقابلة للتحقق آليًا بموجب نموذج بيانات VC وآلية تأمين. يمكن لـ VCs استخدام DIDs ولكنها لا تتطلبها عالميًا.

هل التحكم في DID يثبت من هو الشخص؟

لا. يمكن أن يثبت التحكم في السلطة التشفيرية أو الخاصة بالطريقة المرتبطة بـ DID. يتطلب ربط هذا التحكم بهوية قانونية أو واقعية أدلة إضافية أو تأكيدات موثوقة.

هل يمكن أن يحتوي مستند DID على مفاتيح خاصة؟

لا. تحتوي مستندات DID على مواد تحقق عامة أو مراجع. يجب ألا تظهر مواد المفتاح الخاص ويجب أن تظل محمية بواسطة نظام إدارة المفاتيح الخاص بوحدة التحكم.

المراجع الرئيسية

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Decentralized Identifiers (DIDs) v1.1
• W3C Decentralized Identifier Resolution
• W3C DID Specification Registries
• W3C Verifiable Credentials Data Model v2.0

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