الخلاصة

  • ضمّت مسودة W3C في الأول من أكتوبر فئة مطابقة لمفكّك عناوين DID الشبكي وأمثلة عبر HTTP(S). أزالت نسختا 24 و26 أكتوبر هذه الوظيفة من الربط الشبكي.
  • بقيت طريقة حلّ DID عبر HTTPS محددة في النص. وعلى العميل اختيار المحلّل واستعمال الوثيقة الناتجة للوصول إلى الجزء أو المورد الذي يعيّنه العنوان الكامل.

تصل وثيقة DID إلى التطبيق، فيعلن الخادم انتهاء الرحلة. لكن الطلب كان عن did:example:123#key-1؛ ما زال على التطبيق أن يجد المفتاح ويستخدمه. إيصال تسلّم الطرد لا يفتح العلبة وحده.

في مسودة الأول من أكتوبر، جمع W3C حلّ المعرّف وفكّ عنوان DID تحت ربط HTTP(S)، مع أمثلة وفئة مطابقة مستقلة للخدمة الشبكية. أما مسودة 24 أكتوبر فحذفت فئة مفكّك العنوان، وأخرجت فكّ العناوين من أمثلة HTTP ومن تعريف الربط. تؤكد نسخة 26 أكتوبر التغيير وتذكر إزالة الوظيفة من تعريف OpenAPI أيضاً.

ظلّ للجزء الأول باب واضح. تلزم المسودة المحلّلات المطابقة بدعم GET عبر HTTPS، وتترك POST خياراً. يعيد المحلّل وثيقة DID وبيانات الحلّ الوصفية. هذه نقطة اتصال مشتركة مفيدة حين يتعامل التطبيق مع طرق DID متعددة.

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

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

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