الخلاصة

  • يسجل RFC 9782 ستة أنواع وسائط لأشكال CWT وJWT والحزم المنفصلة وclaims sets غير المحمية، إلى جانب اللاحقة +cwt وأرقام CoAP.
  • يسمح eat_profile الخارجي باختيار المعالج قبل فتح الجسم، لكنه لا يثبت التطابق مع claim الداخلي أو تنفيذ profile كامل.
  • نجاح parsing أو التوقيع لا يساوي موثوقية claims، ونتيجة Verifier لا تساوي إذن Relying Party بالفعل.

أسماء مشتركة للبوابة الأولى

في معمارية RATS ينشئ Attester الـEvidence، ويقيّمها Verifier وفق سياسة ويصدر Attestation Results، ثم يستخدم Relying Party النتيجة وسياسة محلية لاتخاذ فعل محدد. لا يدمج RFC 9782 هذه الأدوار؛ بل يعطي الواجهات لغة واضحة للتمثيل الذي ينتقل بينها.

هناك نوعان لـEAT بصيغة CWT وJWT، ونوعان لحزمة EAT منفصلة بترميز CBOR أو JSON، ونوعان لـUCCS وUJCS غير المحميين. وتحمل CoAP الأشكال نفسها بالأرقام 263 إلى 268. أما +cwt فيتيح للبرامج العامة معرفة البنية الأساسية.

تفيد هذه الأسماء في رفض صيغة غير مدعومة مبكراً، والتفاوض عبر Accept، وإرسال الرسالة إلى parser أضيق. لكنها لا تحدد الموقّع أو الخوارزمية المقبولة أو المفتاح أو claims الواجبة أو freshness أو سياسة القرار. ولا يثبت اسم الحزمة ارتباط الأجزاء المنفصلة بالـdigests المحمية.

يظهر الحد بوضوح مع UCCS/UJCS. يشترط RFC 9781 قناة آمنة تصادق المرسل وتحمي integrity، ومع confidentiality تصادق المتلقي أيضاً. عند خروج claims set من القناة تنتهي تلك الحماية، ويصبح التخزين أو الإرسال اللاحق تسليماً جديداً. وفي المقابل لا تصادق القناة CWT كاملاً يمر داخلها؛ تبقى COSE envelope ومسار المفتاح مسؤولين عن ذلك.

اسم profile يختار قائمة الفحص

يضيّق EAT profile خيارات JSON/CBOR، والتداخل، وCOSE/JOSE، والخوارزميات، وتعيين المفاتيح، والحزم، والclaims والحداثة. يحمل EAT داخلياً eat_profile على شكل URI أو OID. يسمح RFC 9782 بوضع القيمة نفسها في media type، فيختار router معالج profile قبل فحص الجسم.

هذه فائدة تشغيلية حقيقية، لأنها تكشف profile غير المدعوم عند الحافة وتقلل parser الشامل. لكن parameter الخارجي يظل تصريحاً من المرسل. بعد decode آمن يجب تمييز الغياب والتطابق والتعارض مع claim الداخلي. قد يعني التعارض client مرتبكاً أو intermediary قديماً أو محاولة استبدال، ولا يجوز تسويته بصمت.

ولا يثبت التطابق conformant behaviour. يمنع RFC 9711 استخدام eat_profile لتعريف partial profile. يجب أن يمكّن full profile كل receiver ملتزم من decode وverify وفحص freshness لكل EAT من sender ملتزم. قد يظهر URI الصحيح مع algorithm محظور أو claim ناقص أو nonce خاطئ. الاسم يحدد القواعد؛ التنفيذ وحده يثبتها.

البايتات أولاً ثم الحماية ثم المعنى

يصف RFC 9782 أنواع الوسائط بأنها مجرد دلائل لتطبيق المعالجة. يجب على التطبيق التأكد من مطابقة البيانات الحقيقية للصيغة المتوقعة مهما كان النوع المعلن، والتوقف عند الفشل. يؤدي التخمين المتسامح إلى cross-protocol attack أو privilege escalation. ويحذر RFC 9110 من content sniffing، بينما يطلب RFC 8725 typing واضحاً وقواعد متعارضة لأنواع JWT المختلفة.

لذلك يسجل النظام أولاً header وhash البايتات، ثم route وhandler وparser. بعد ذلك يسجل envelope والخوارزمية والمفتاح وtrust anchor والنتيجة، أو هوية القناة ونطاقها في الصيغ غير المحمية. وتحتاج detached bundle إلى مقارنة كل digest.

بعدها فقط يمكن تفسير claims. يعرّف RFC 9711 معنى claim ولا يضمن مستوى أمان الجهاز الذي أنتجها. يربط التوقيع الصحيح البايتات بمفتاح ضمن نموذج محدد، لكنه لا يثبت صدق القياس. يحتاج Verifier إلى معرفة التنفيذ وendorsements وreference values والسياسة.

Freshness فحص مستقل وواجب لمنع replay. قد يكون token أصلياً لكنه قديماً. وفي النهاية يصدر Verifier Attestation Results، بينما يقرر Relying Party فعلاً يخص مورداً ووقتاً ومخاطر محددة. يمكن رفض فعل رغم نتيجة إيجابية، أو منح صلاحية محدودة ومؤقتة.

السلسلة الكاملة هي: النوع وprofile الخارجي → البايتات → المعالج → الحماية → profile وclaims الداخلية → المطابقة والحداثة → appraisal → الفعل. يسجل IANA اللغة المشتركة في الطبقة الرمزية؛ وتظهر الحقيقة التشغيلية فقط عندما تنفذ البرامج الحدود نفسها، وهو الفرق الذي يؤكد عليه Heng Lu في مبدأ running code.

المصادر