Кратко

  • RFC 3504 починила три исполнимые поверхности IOTP v1: грамматику DTD, продолжение исходной сделки после аутентификации и список типов содержимого для подписи IOTP.
  • Применение исправлений подтверждало соответствие уточнённой спецификации, но не успех аутентификации, полномочия подписанта, разрешение списания, расчёт, доставку, внедрение или распространение.

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

RFC 3504 была опубликована в марте 2003 года как Informational. Она собрала ошибки, обнаруженные после выхода спецификаций IOTP версии 1, прежде всего огромной RFC 2801. IOTP была независимой от платёжной системы торговой основой: магазин, обработчик оплаты, доставка и поддержка могли принадлежать разным организациям.

Такое распределение делало общий смысл существенным. Пересекая границу организаций, сообщение должно было сохранять сделку и действие. Разница грамматики или перехода могла заставить двух участников с одинаковым заявленным RFC вести себя по-разному.

Первое исправление касалось PackagedContent. В DTD типы атрибутов Name и Content были перепутаны. Исправление делало Name типом NMTOKEN, а ContentCDATA. Этот контейнер использовался в запросах аутентификации, заказах, сведениях бренда, данных платёжной схемы, квитанциях и доставке.

Код из старого объявления мог применить лексическое ограничение к неверному значению. Один участник принимал то, что другой отвергал. Слова «поддерживает RFC 2801» скрывали вопрос, какая именно грамматика исполнялась.

Второе изменение было короче: элемент Attribute имел неверную форму ( ANY ) вместо ANY. Валидатор не уполномочен угадывать намерение. Без общей поправки команды могли создать разные патчи, отключить проверку или добавить несовместимые исключения.

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

Третье исправление затрагивало состояние. Для совмещения аутентификации с другой транзакцией IOTP исходный текст говорил, что первоначальная транзакция после успеха перезапускается. RFC 3504 заменила это на продолжается.

Идентичность проходила через ворота. Аутентификация была условием внутри большого обмена, а не создателем второй покупки. Идентификатор, накопленные компоненты, журнал идемпотентности и область разрешения оставались у исходного контекста.

«Продолжается» не сообщало, что аутентификация состоялась. Оно определяло следствие при успехе. Системе по-прежнему требовалось решение, связанное с субъектом, методом, вызовом, ответом и сделкой. Подтверждённая личность не разрешала автоматически оплату или доставку.

Список типов подписей тоже был неполным. Он охватывал предложение, оплату, доставку, аутентификацию и ping, но пропускал AuthenticationStatus, InquiryRequest и InquiryResponse. RFC 3504 добавила их и разрешила любым ролям.

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

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

Поэтому errata может быть исполнимой зависимостью. Инвентаризация должна фиксировать базовый документ, набор поправок, артефакт parser или schema и тесты. Два заявления об одном RFC без происхождения могут описывать разные машины.

Метаданные показывают ту же границу. Заголовок RFC 3504 не объявляет Updates: 2801. Erratum 2947 RFC Editor, удерживаемый до обновления документа, говорит, что связь нужна из-за нормативных изменений. Текст уже менял исполнение, хотя документная связь не выражала всю силу.

Честная цепочка начинается с точной редакции и поправок, затем идут воспроизводимая сборка, принятый документ, сохранённая идентичность, решение аутентификации, распознанный тип, проверенная подпись, разрешённое действие и внешняя платёжная или доставочная квитанция.

Грамматика отвечает за интерпретируемость, продолжение — за выживший контекст, тип — за заявленный предмет подписи. Ни одна ступень не означает оплаченную и исполненную покупку.

Источники