الخلاصة

  • وضعت RFC 3505 متطلبات لهرم مشترك من حقول التجارة الإلكترونية كي تقل حاجة المحافظ والنماذج وأنظمة الخلفية إلى التخمين والتحويل.
  • لم تكن بديلاً عن TLS أو SET أو EMV أو XML أو IOTP؛ ففهم اسم الحقل لا يثبت هوية التاجر أو موافقة المستخدم أو تفويض الخصم أو تسوية المال أو تسليم السلعة.

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

عالجت RFC 3505، المنشورة في مارس 2003 بوصفها وثيقة Informational، هذا الاحتكاك كمشكلة قابلية تشغيل مشترك. كان على الإصدار الثاني من ECML أن ينظم كائنات معالجة الدفع في هرم واحد، وأن يخدم المعاملات بين المستهلك والتاجر وبين الشركات، وأن يوسّع عمل نماذج HTML السابق إلى XML ووسائل دفع إضافية وأنظمة خلفية.

كان النطاق واسعاً: التكلفة والإيصال والعملة والبطاقة والدفع والبيانات المصرفية أو بيانات الاتصالات، إضافة إلى الشيك الإلكتروني وACH والدفع بالهاتف أو الجهاز المحمول وبطاقات المشتريات ومحافظ الشركات. ومع ذلك ظل مبدأ التصميم مقتصداً: الحفاظ على وظائف الإصدار 1.1، وإضافة أقل عدد عملي من الحقول، والاستفادة من بنية الويب الأوسع القائمة على URI والطبقات وقابلية التوسعة.

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

رفضت RFC 3505 الخلط بين هذه الراحة والأمن. نصت على أن ECML v2 ليست بديلاً عن TLS أو SET أو EMV أو XML أو IOTP. توفر تلك التقنيات قدرات أخرى، منها سرية القناة وعدم إنكار المعاملة واختيار مخطط الدفع ودعم البطاقات الذكية وتدفق التجارة. تسمي ECML البيانات، ولا تستوعب كل الضوابط المحيطة بها.

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

حتى الصحة النحوية بقيت دليلاً محدوداً. كان المطلوب DTD وربما schema وأمثلة XML مختبرة ومقارنة بالمفردات السابقة. يثبت اجتياز هذه الاختبارات أن الأسماء والبنية تتبع القواعد، لا أن رقم البطاقة يخص المستخدم، أو أن السعر صادق، أو أن الصفحة للتاجر الحقيقي، أو أن المعالج وافق على الخصم.

كشف اقتراح حقل ترجمة مخفي مشكلة الانتقال. يستطيع ذلك الحقل ربط حقول ECML القياسية بحقول التاجر القديمة، فيتبنى التاجر النظام من دون إعادة كتابة التطبيق. ينخفض الثمن التقني، لكن البيانات الحساسة قد تمر عبر روابط لا يراها المستخدم. تحل التوافقية سؤال كيفية التسليم، ولا تحل سؤال الموافقة عليه.

نشرت RFC 4112 في 2005 مواصفة ECML v2 الفعلية. عرّفت أسماء هرمية وقدمت XML كلغة نموذجية مع السماح بترميزات وبروتوكولات أخرى. يقيّد الامتثال الأسماء والبنية على السلك، لا الملصقات المرئية. يستطيع متجر عرض العربية مع الحفاظ على الدلالة الآلية المشتركة.

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

كما وصفت حالتا query وassert نية الرسالة فقط. تطلب الأولى قيمة وتقدم الثانية قيمة. يبيّن اسم الحقل ما طُلب أو ما أُعلن، لكنه لا يصادق على السائل ولا يجعل الإعلان صحيحاً. تحتاج المحفظة قبل الإجابة إلى سياسة مستقلة تفحص الطرف المقابل والغرض واللحظة.

على الويب كان Ecom_SchemaVersion يعرّف إصدار مجموعة الحقول ويتيح اختيار التفسير الصحيح. حتى وهو مطلوب في كل معاملة ECML على الويب، فإنه لا يعرّف التاجر ولا يتحقق من الصفحة ولا يحمي القناة. معرفة الإصدار ليست مصادقة على الوجهة.

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

أبقى قسم الأمن الاعتماد الخارجي صريحاً. تحتاج المعلومات الحساسة إلى السرية والحماية من التعديل غير المصرح. وقد تعتمد الأصالة على أمن الكائن مثل توقيعات XML أو CMS، أو على أمن القناة مثل TLS أو IPsec. تسمي المواصفة خيارات، لكنها لا تضع آلية حماية شاملة.

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

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

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

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

المصادر