Кратко

  • RFC 3506 определил ваучер как <эмитент, обещание, держатель> в логическом множестве действующих ваучеров VVS и разделил выпуск, передачу, предъявление и потребление.
  • Документ, подпись и API могли описывать или запускать действие, но не доказывали сами по себе текущего права, отсутствия повторного погашения или исполнения обещания.

В 2003 году можно было хранить билет на защищённой карте или проверять его на сервере. Эти архитектуры требовали разных протоколов, задержек и моделей доверия. RFC 3506 не объявил одну из них обязательной. Он определил инвариант, который обе обязаны сохранять.

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

Формула включала эмитента I, обещание P и держателя H: <I,P,H>. Обещание могло означать скидку, зарезервированное место или месяц доступа. Его можно было выразить естественным языком или XML. Но описание обещания не устанавливало, существует ли ещё конкретное право и кто им распоряжается.

Полномочия делились между четырьмя ролями. Эмитент создавал ваучер и отвечал за содержание. Держатель владел, передавал и погашал. Сборщик проверял и исполнял обещание. Провайдер VTS не допускал нескольких действующих держателей или использования сверх разрешённого числа раз.

VTS логически управляла Valid Voucher Set, VVS. Множество начиналось пустым и содержало действующие тройки. Оно не обязано было находиться в единой базе. Состояние могли хранить распределённые карты, серверы эмитентов или доверенные третьи стороны. Модель ограничивала результат, а не навязывала центр.

Выпуск добавлял <I,P,H> по воле эмитента. Передача переписывала его в <I,P,H'> по воле прежнего держателя. Копия прежнего файла могла сохраниться, но действующее право не оставалось вместе с ней. Передача была изменением признанного состояния, а не копированием с надеждой на честное удаление.

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

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

Подпись не обеспечивала всё. Для непередаваемого права эмитент мог подписать I, P и H. При передаче H менялся и исходная подпись переставала соответствовать. Для защиты от двойного погашения всё равно требовалась онлайн-проверка состояния или защищённое устройство. Подлинное утверждение не равно актуальной исключительности.

RFC также разделил защиту от повторения и приватность. Новый обладатель не должен автоматически видеть нынешних и прежних держателей. Одновременно система должна помогать оценивать подлинность эмитента и ваучера. Достаточная история для отказа дубликату не даёт права раскрывать полную историю людей.

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

Работу разделили на возможный протокол передачи, VTS-API и Generic Voucher Language. Минимальная семантика состояния могла быть общей, а реализации — развиваться по результатам практики. Это сохраняло выбор вместо преждевременной власти одного механизма.

RFC 4153 в 2005 году описал XML Voucher Component. Компонент задавал ценность, предмет, ограничения, эмитента и провайдера. Он прямо не являлся ваучером: множество экземпляров могло ссылаться на одно описание. Копирование XML не создавало новых прав.

Компонент считался корнем доверия и нуждался в защите. Безопасный канал или XML-подпись могли предотвратить изменение обещания. Владение экземпляром, защита от копирования и двойного погашения обычно находились вне компонента. Целый документ не был снимком VVS.

RFC 4154 добавил единый интерфейс: выпуск добавлял, передача переносила, потребление удаляло, предъявление сохраняло. API скрывал различия реализаций, но не создавал полномочия вызывающей стороны и не заменял подтверждение состояния.

Примечание IESG предупреждало: интерфейс предполагает доверенный модуль VTS, но не задаёт аутентификацию приложения. Требовалась дополнительная защита. Корректный вызов не доказывал право пользователя, а успешный ответ — выдачу товара.

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

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

Историческая точность RFC 3506 состояла в выборе правильного минимума. Копирование информации неизбежно. Поэтому право нельзя отождествлять с ближайшим файлом. XML описывает, подпись удостоверяет заявление, API просит изменить состояние. Только действующая тройка и последующее исполнение превращают описание в полезное право.

Sources