الخلاصة

  • يتحقق AIP على مرحلتين: يثبت التوقيع حيازة المفتاح المعروض، ثم يطابق المدقّق ذلك المفتاح مع المفتاح المرتبط بـ agentDid في سجله أو في وثيقة DID تم حلّها.
  • تسند المراجعة 03 هويات did:web المحصورة بالمزوّد وهويات did:opena2a على مستوى المنظومة إلى سطحي سلطة مختلفين. نوع الوكيل وغرضه المعلنان لا يمنحانه تفويضاً.

مرّت الرسالة بكل الاختبارات السريعة. كانت المهلة مفتوحة، والـ nonce جديداً، والتوقيع صحيحاً تحت المفتاح العام الموجود داخل الرد. ومع ذلك، لم يكن في سجل المدقّق ما يربط ذلك المفتاح بالوكيل المذكور في التحدي.

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

هذه هي الحدود العملية في المراجعة 03 من OpenA2A Agent Identity Protocol (AIP). نُشرت في 2 أكتوبر 2026 بصفتها مسودة إنترنت فردية وتنتهي في 3 أبريل 2027. ليست RFC، ولا وثيقة لفريق عمل، ولا إجماعاً من IETF، ولا دليلاً على تشغيل إنتاجي. يذكر النص Standards Track كوجهة يريدها المؤلفون، لا كصفة نالها المستند.

ما الذي يشمله التوقيع فعلاً

ينشئ المدقّق تحدياً فيه 32 بايت عشوائياً، وagentDid المدّعى، وnonce عشوائي من 16 بايت، وissuedAt وexpiresAt وissuerDid. تستخدم الأوقات UTC وفق RFC 3339، ضمن نافذة مدتها خمس دقائق.

يوقّع الوكيل السلسلة التالية:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

ويحمل الرد أيضاً publicKey وkeyId وsignedAt وalgorithm. هذه الحقول الأربعة ليست جزءاً من السلسلة الموقعة. يمكن استخدام المفتاح المرفق لاختبار الحيازة، لكنه لا يستطيع منح نفسه صفة المفتاح المعتمد. فأي جهة تستطيع إنشاء زوج مفاتيح تستطيع إنتاج توقيع صحيح بمفتاحها.

لذلك يجب أن يبقى وصف النتيجة الأولى ضيقاً: «التوقيع صحيح تحت المفتاح المقدَّم». لا يصبح «تم توثيق هوية الوكيل» إلا بعد مصدر ربط مستقل.

إثبات الحيازة ليس إثبات الانتماء

تتحقق القاعدة الأولى في AIP من التوقيع بالمفتاح الموجود في الرد. ثم تقارن القاعدة الثانية ذلك المفتاح بالمفتاح المرتبط سلفاً بـ agentDid في سجل المدقّق أو في وثيقة DID محلولة. وتقول المسودة صراحة إنه لا يجوز الوثوق بـ publicKey المضمّن وحده.

حداثة الرد، واستعمال nonce مرة واحدة، ووجود issuerDid ضمن قائمة موثوقة ضوابط إضافية. لكنها لا تنشئ رابطة هوية. فالرد الحديث غير المعاد من مفتاح غير مرتبط يظل صادراً عن مفتاح غير مرتبط.

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

طريقة DID تحدد مَن يملك حق التسمية

تخصص المراجعة 03 طريقة did:web للهويات الواقعة ضمن نطاق المزوّد، وينشر المزوّد وثيقة DID عبر مسار الويب. وهكذا يصبح التحكم بالنطاق وTLS والنشر والذاكرة المخبأة والاسترداد جزءاً من سلطة الهوية.

أما did:opena2a فمخصص لهويات على مستوى المنظومة، ولا يقدّم مزوّد الهوية وثائقها. وتصف الصيغة القديمة did:aip:aim_ بأنها اسم بديل متقادم. ينبغي للمدقّق أن يعامل المعرّف كقيمة معتمة ويرسله إلى المحلّل المناسب، لا أن يستنتج الثقة من بادئة مألوفة.

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

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

الوصف الذاتي لا يكتب تصريحاً

حقل type معلوماتي ولا يجوز أن يقود قراراً أمنياً. ويمكن لـ declaredPurpose الاختياري أن يضيف سياقاً للهوية أو الإفادة، لكن غيابه لا يبرر الرفض ووجوده لا يجوز أن يدخل في التفويض.

تبدو عبارات مثل «وكيل مشتريات» أو «مساعد أبحاث» كأنها أدوار، لكنها تبقى ادعاءات ذاتية بلا إثبات مستقل. وكذلك يجب أن تعتمد درجات الثقة على مدخلات قابلة للتحقق بصورة مستقلة.

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