Summary

  • RFC 3506 defined a voucher as <issuer, promise, holder> inside a logically managed Valid Voucher Set; issue, transfer, presentation and consumption changed that state in different ways.
  • XML, signatures, smart cards and APIs could describe or operate the system, but none alone proved current ownership, successful redemption or delivery of the promised good.

Imagine that a concert ticket exists as a small digital file. Its owner emails a copy to a friend and keeps another copy. Both files contain the same seat, time and issuer. If possession of the bytes were possession of the ticket, one reserved chair would acquire two valid claimants. The file format could describe the collision perfectly and still do nothing to resolve it.

RFC 3506 began from that difficulty. Published as an Informational RFC in March 2003, it looked across loyalty points, coupons, gift certificates, event tickets, telephone cards and delivery notes. These objects promised different things, yet all needed a way to distinguish a description of value from the right to claim it.

The document’s formal move was spare. Let I be an issuer, P the issuer’s promise and H a holder. A voucher was the three-part relation <I,P,H>. The promise might say that fifty points earn an item, a coupon reduces a purchase by half, or a named seat has been reserved. It could be expressed in ordinary language or XML attributes. But the promise text was only one member of the tuple. It did not contain the whole fact of ownership.

Four roles divided the authority. The issuer created the voucher and guaranteed the promise. The holder owned, transferred or redeemed it. The collector examined it and performed the promised service. The Voucher Trading System provider maintained the condition that one voucher was not assigned to several holders or used more times than its type allowed. Each role supplied a different receipt. None silently inherited the powers of the others.

The system’s centre was the Valid Voucher Set, or VVS. RFC 3506 defined it as a logical set of valid <I,P,H> tuples, initially empty. “Logical” mattered. The set could live in a central service, several issuer-operated servers or tamper-resistant cards carried by users. The RFC specified the invariant without pretending that one physical architecture had already won.

Issue added a new tuple to that set with the issuer’s intention. Transfer did not make another file and hope the old holder forgot theirs. It rewrote <I,P,H> as <I,P,H'>, reflecting the original holder’s intention. The old and new descriptions might remain visible in caches or messages, but only the state transition determined which holder the VTS treated as current.

Redemption split into two operations. Presentation exposed the tuple while preserving ownership, appropriate for a licence or passport that could be shown repeatedly. Consumption deleted the tuple, voided it or reduced the remaining number of uses, appropriate for a concert ticket or telephone card. This distinction prevented the word “redeemed” from hiding whether a right survived the encounter.

The security requirements followed from the model. Only the issuer could create a valid voucher. Only the current holder could initiate transfer or redemption. Circulation could not alter the voucher except for the authorized holder rewrite. A consumed voucher could not be redeemed again. At any moment a particular voucher was to have one valid holder, unless its own terms allowed multiple use.

Those were not merely signature requirements. RFC 3506 explained that an issuer-signed certificate could work for a non-transferable voucher: sign I, P and H together. Transfer, however, changed H and broke that original signature. More importantly, duplicate redemption still required online state checking or a tamper-resistant device. Cryptography could authenticate a statement while leaving exclusivity and current state unsolved.

Privacy and trust introduced further tension. The document recommended concealing current and previous holders from whoever later obtained a voucher. It also wanted a way to judge issuers and voucher authenticity. A useful system therefore needed both history sufficient to reject duplication and boundaries sufficient not to expose a complete ownership trail to every possessor.

The anti-centralization language was unusually direct. RFC 3506 said a universal broker or authenticator should not be assumed because one central organization would be excessively frail. Yet it did not respond by requiring one decentralized technique. Offline smart cards and online services faced different trade-offs. The authors declined to standardize a universal transfer protocol at that point.

That restraint was architectural, not indecision. The work separated three possible layers: a voucher transfer protocol, a common application interface and a Generic Voucher Language. Common semantics could progress while implementations remained free to settle the hardest trust and performance questions through evidence.

RFC 4153 supplied the description layer in 2005. Its XML Voucher Component defined the promise, value and restrictions and identified relevant issuer and provider information. It then stated the crucial boundary explicitly: a Voucher Component was not a voucher. Many voucher instances could share one component. Copying the component multiplied descriptions, not valid rights.

RFC 4153 treated the component as a root of trust and warned that altering it could make a forged voucher appear valid. Secure delivery or an object signature could protect that description. Yet instance-specific controls—ownership, reproduction and duplicate redemption—normally remained outside it. A valid component answered “what is promised under which restrictions?” It did not answer “who currently owns an unspent instance?”

RFC 4154 supplied an application interface. A wallet could call uniform methods to issue, transfer, consume or present across different VTS implementations. The later API preserved RFC 3506’s state logic: issue added instances, transfer removed them from one holder and stored them for another, consume removed them, and present left them intact.

The IESG note on RFC 4154 kept another boundary visible. The interface assumed that the VTS plug-in was trusted by its user, but it did not specify application authentication. The API was not safe without an additional authentication mechanism. A correctly shaped call therefore did not prove the caller’s authority, the plug-in’s identity, a committed transition or the collector’s later performance.

The evidence ladder is longer than a voucher file. First comes a promise description. Then trust in the named issuer and provider. Then a live voucher instance in VVS. Then proof that the current holder authorized an operation. Then an accepted and committed state transition. Only after that can a collector deliver the good or service, and only after delivery can a user or business observe the outcome.

The name “voucher” later appeared in device-onboarding protocols, including BRSKI. That vocabulary collision does not create continuity. RFC 3506 concerned transferable commercial rights such as coupons, tickets and points. A device voucher binds onboarding assertions in a different protocol family. Shared words are not shared state machines.

Nor does the RFC itself prove adoption. Informational publication records a model and its requirements. It does not show that merchants deployed it, that independent providers interoperated, that users accepted its trust model or that collectors delivered what they promised. Those claims require implementation, operational and outcome evidence.

The lasting contribution is narrower and more useful. RFC 3506 refused to let representation swallow reality. The XML could describe a promise. A signature could protect a statement. An API could request a transition. A card or server could hold state. The redeemable right existed only where the system’s bounded actors maintained the valid relation and honoured it.

A copied file can be perfectly authentic and economically empty. A valid right is not whatever bytes happen to be nearest the reader. It is a current, authorized position in a state system whose transitions preserve exclusivity. That was the discipline RFC 3506 put underneath the cheerful word “voucher.”

Sources