摘要

  • RFC 3506 用 <发行者, 承诺, 持有人> 三元组定义凭证，并以逻辑上的有效凭证集合 VVS 管理发行、转让、出示与消费。
  • XML、数字签名、智能卡和 API 都只能承担有限角色；它们本身不能证明当前持有人、未消费状态，更不能证明商品或服务已经交付。

设想两个完全相同的电子优惠券文件摆在收银台前。它们的 XML 一致，签名一致，折扣条件也一致。仅凭文件内容，收银台无法知道哪一份仍代表有效权利，哪一份只是旧副本。格式可以准确描述承诺，却不能单独维护稀缺性。

2003 年 3 月发布的 RFC 3506 是一份信息类文档。它试图为积分、优惠券、礼券、活动门票、电话卡和提货单找到共同模型。这些东西并不都是货币，却都代表向某个发行者或服务方主张商品、服务或折扣的权利。

文档把凭证写成三元组。I 是发行者，P 是发行者对持有人的承诺，H 是持有人；凭证就是 <I,P,H>。承诺可以是满五十积分换一件商品、一次五折优惠、一个月访问权限，或者某场演出的固定座位。它可以用自然语言描述，也可以用 XML 属性表达。但 XML 只表达 P，并不独自回答谁现在拥有这项权利。

RFC 3506 进一步划分四种角色。发行者创建凭证并保证承诺内容；持有人拥有、转让或兑付凭证；收集者检查凭证并履行承诺；VTS 提供者维护有效性，防止同一凭证同时归属多个持有人，或在规则不允许时被重复使用。

系统核心是有效凭证集合 VVS。它是所有可能三元组中的一个逻辑子集，初始为空。“逻辑”二字很关键：VVS 不必放在唯一中央数据库中。它可以由持有人携带的分布式智能卡维护，也可以分散在发行者或可信第三方的多台服务器上。RFC 固定的是状态不变量，而非物理部署权力。

发行操作创建 <I,P,H> 并加入 VVS。转让则把 <I,P,H> 改写为 <I,P,H'>，表达原持有人的意愿。旧文件可以仍在缓存、邮件或备份中，权利却不应留在旧持有人名下。转让不是复制后期待对方删除，而是对有效关系进行受控改写。

兑付又分两类。出示仅向收集者展示 VVS 中的三元组，之后所有权仍然存在，适用于许可证或可重复检查的证件。消费则删除三元组、作废所有权或减少剩余使用次数，适用于一次性门票或储值电话卡。两者若被一个模糊的“已使用”覆盖，运营者便无法判断权利是否还活着。

安全要求直接来自这个状态模型。只有发行者能使新凭证有效；只有当前持有人能发起转让或兑付；除持有人变更外，流通中不得任意改写凭证；一旦被消费，不得再次兑付；除非凭证类型明确允许多次使用，同一时刻只能有一个有效持有人。

数字签名无法包办这些要求。RFC 指出，不可转让凭证可以由发行者对 I、P、H 整体签名。但转让会改变 H，原签名随之失效。更重要的是，防止重复兑付仍需要在线状态检查或防篡改设备。签名能证明某段声明来自谁，不能单独证明这项权利此刻尚未消费。

隐私与可追溯性也不能被混成一个目标。RFC 建议向后来获得凭证的人隐藏当前及历史持有人，同时又要求系统支持发行者真实性判断和防伪。系统必须保存足够证据拒绝重复使用，却不因此取得向每个参与者公开完整持有人链的权力。

文档明确反对假设一个销售所有凭证的中央经纪人，或认证所有发行者的中央机关。单一组织失效会拖垮全局，过于脆弱。但 RFC 3506 并未把这一观察偷换成某种区块链义务。离线智能卡与在线服务器有不同成本和风险，当时强行统一转让协议并不现实。

这种克制把未来工作分成三个层面：凭证转让协议、VTS 应用接口、通用凭证语言。最小公共层先说明权利如何存在、移动和终止，具体技术则保留选择空间，等待实现与运行证据。

2005 年的 RFC 4153 完善了描述层。它定义 XML Voucher Component，用来表达价值、商品、期限、参与者限制以及发行者和 VTS 提供者信息。该文档特别说明：Voucher Component 不是凭证；多个凭证实例可以共享同一个组件。复制组件只增加描述副本，不增加有效权利。

组件仍需安全保护。如果恶意者能篡改这个信任根，伪造承诺就可能看起来有效。安全信道或 XML 签名可以保护组件传递。然而实例的所有权、防复制和防重复兑付通常存在于组件之外。保护说明书，不等于证明某个未消费实例属于眼前的人。

RFC 4154 则提供统一 API，让钱包或应用以相同方式调用发行、转让、消费和出示。接口保持原模型：发行增加实例，转让从发送者移除并交给接收者，消费删除，出示不删除。API 规范化了动作入口，并没有替代背后的状态提交。

IESG 附注揭示另一个边界：RFC 4154 假定用户信任 VTS 插件，却没有规定应用认证方式，因此不能在缺少额外认证机制时直接使用。函数调用成功不能证明调用者有权，返回成功也不能证明收集者已经履约。

完整证据链至少包括：承诺描述存在；发行者与提供者可信；某个实例确实位于 VVS；当前持有人完成认证并授权；操作被接受；状态变化可靠提交；收集者接受凭证；商品或服务实际交付。把前一步叫成后一步，就是把符号当作现实。

后来设备引导协议也使用 voucher 一词，但那是不同的技术家族。RFC 3506 讨论可转让的商业权利；BRSKI voucher 绑定设备加入域的断言。名称相同不意味着参与者、状态机或证据边界相同。

RFC 的存在同样不等于部署。信息类文档证明有人提出了一套结构化模型，不证明商家采用、不同 VTS 互操作、用户认可，或收集者实际交货。那些结论需要实现、运行和结果证据。

RFC 3506 的历史价值正在于没有把“电子化”误写成“文件化”。承诺可以写进 XML，声明可以由签名保护，动作可以由 API 请求，状态可以放在卡或服务器中。权利只有在受限角色共同维护有效关系时才存在。复制文件很容易；复制合法兑付权，必须在系统里失败。

Sources