Кратко

  • RFC 3505 задала требования к общей иерархии полей электронной торговли, чтобы кошелькам, формам и внутренним системам приходилось меньше угадывать и преобразовывать.
  • Документ прямо не заменял TLS, SET, EMV, XML или IOTP: распознанное имя поля не доказывало личность продавца, согласие пользователя, разрешение списания, расчёт или доставку.

Проблема ранних интернет-магазинов выглядела мелкой. Один продавец называл фамилию “surname”, другой — last_name, третий прятал те же сведения в собственной иерархии. Человек читал подпись и набирал данные заново. Программный кошелёк не мог надёжно догадаться, что означает каждое окно.

RFC 3505, опубликованная в марте 2003 года как документ Informational, рассматривала это трение как вопрос совместимости. ECML версии 2 должна была дать иерархически организованные объекты обработки платежей для отношений потребителя с продавцом и для обмена между компаниями. Предыдущую работу с HTML-формами предлагалось распространить на XML, дополнительные способы оплаты и внутренние системы.

Охват был широким: стоимость, квитанция, валюта, карта, платёж, банковские и телекоммуникационные данные; электронные чеки, ACH, оплата с телефонов и карманных устройств, закупочные карты и корпоративные кошельки. При этом принцип проектирования оставался сдержанным: сохранить возможности версии 1.1, добавить минимум новых полей и использовать общую архитектуру Web — URI, слои и расширяемость.

Получался договор о словаре. Если кошелёк узнавал структурированное имя города доставки, он мог предложить значение, не разбирая человеческую подпись. Если внутренняя система понимала ту же платёжную иерархию, она могла сопоставить понятие своему процессу. Общие имена снижали стоимость перевода между независимыми программами, но не объединяли их в одну область доверия.

RFC 3505 не смешивала это удобство с безопасностью. ECML v2 не была альтернативой TLS, SET, EMV, XML или IOTP. Эти технологии предоставляли иные возможности: конфиденциальность канала, неотказуемость сделки, выбор платёжной схемы, работу со смарт-картами или торговый процесс. ECML именовала данные, а не поглощала все меры контроля вокруг них.

Граница была особенно важна из-за чувствительности данных. Имена, адреса, номера счетов, сведения карты и учётные данные могли утекать быстрее, когда кошелёк понимал их автоматически. Поэтому защита зависела от транспортной инфраструктуры и от приложений, которые хранили или выдавали информацию. Словарь не обязан изобретать механизм безопасности, но спецификация обязана предупреждать реализаторов.

Правильная структура тоже оставалась ограниченным свидетельством. DTD, возможная schema, проверенные примеры XML и сравнение с прежними словарями показывали, что имена и расположение подчиняются грамматике. Они не доказывали, что карта принадлежит пользователю, цена честна, страница создана настоящим продавцом или платёжный процессор разрешил списание.

Предложение скрытого поля преобразования показывало трудность миграции. Оно могло сопоставлять стандартные поля старым полям продавца и позволять внедрение без переписывания кода. Стоимость снижалась, но чувствительные данные проходили через невидимые пользователю соответствия. Совместимость отвечала, как передать, а не давал ли пользователь согласие.

В 2005 году RFC 4112 опубликовала спецификацию ECML v2. Она определила иерархические имена, показала XML как пример синтаксиса и сохранила возможность других кодировок и протоколов. Соответствие касалось имён и структуры при передаче, а не надписи на экране. Магазин мог использовать русский интерфейс при общей машинной семантике.

Значения MIN в таблице задавали минимальную ёмкость, которую обязана принимать форма. Они не были нижним пределом достоверности. Короткое имя, длинный адрес или необычный телефон могут быть настоящими. Использование ёмкости как проверки личности превращает основание совместимости в ложное правило о людях.

Режимы query и assert описывали только намерение сообщения. Первый спрашивал значение, второй его сообщал. Имя поля показывало, что запросили или заявили, но не аутентифицировало спрашивающего и не делало ответ истинным. До автоматического ответа кошельку всё ещё требовалась отдельная политика по контрагенту, цели и моменту.

В Web поле Ecom_SchemaVersion обозначало версию набора и помогало выбрать правильное толкование. Оно требовалось в каждой ECML-транзакции Web, но не идентифицировало продавца, не проверяло страницу и не защищало канал. Узнать версию — не значит аутентифицировать конечную точку.

Многостраничные формы создавали ещё один риск: автоматическое заполнение могло продолжать раскрытие после фактического завершения покупки. Ecom_TransactionComplete было подсказкой остановиться до нового разрешения. Она ограничивала раскрытие, но не являлась платёжной квитанцией и не доказывала авторизацию, захват, расчёт, исполнение или принятие покупателем.

Раздел безопасности явно сохранял внешние зависимости. Чувствительной информации требовались конфиденциальность и защита от изменения. Подлинность могла обеспечиваться защитой объекта, например подписями XML или CMS, либо защитой канала, например TLS или IPsec. Спецификация называла варианты, но не устанавливала универсальный механизм.

Контроль пользователя над раскрытием оставался необходимым. На общедоступном терминале должна отключаться память персональных данных, а сохранённым данным требовалась защита. Скрытые и стандартные значения можно было злонамеренно изменить перед возвратом. Стандартная структура делала обработку предсказуемой, а не окружающее приложение добросовестным.

Поэтому честная лестница квитанций начинается с «имя поля распознано». Затем отдельно следуют структурная корректность, аутентифицированный контрагент, разрешённое пользователем раскрытие, защищённая передача, принятие приложением, авторизация платежа, клиринг или расчёт и доставка. Прыжок от первых двух ступеней к «оплачено» превращает машинную читаемость в коммерческое утверждение.

Публикация RFC также не доказывает внедрение. RFC 3505 записала требования, а RFC 4112 позднее стала спецификацией Standards Track. Ни один факт сам по себе не подтверждает поддержку браузерами, использование кошельками, совместимость продавцов, результат для приватности или успешные сделки. Для этого нужны свидетельства реализации и эксплуатации.

Узкий вклад ECML всё же был значим. Система уменьшила один вид трения, не заявляя решение всех слоёв. Общее имя — это возможность. Была ли возможность разрешена, защищена и завершилась ли экономическим результатом, должны отвечать другие участники и другие квитанции.

Источники