Resumo

  • RFC 3506 definiu o voucher como <emissor, promessa, titular> em um conjunto lógico de vouchers válidos, permitindo distinguir emissão, transferência, apresentação e consumo.
  • Um componente XML, uma assinatura ou uma chamada de API podia apoiar o sistema, mas não provar sozinho titularidade atual, ausência de gasto duplicado nem entrega do benefício.

Uma conta de fidelidade acumula cinquenta unidades e continua existindo depois de cada consulta. Um ingresso para o assento A-24 desaparece economicamente quando a catraca o consome. Se ambos forem apenas arquivos, o sistema perde a diferença mais importante: qual direito permanece válido após a operação.

RFC 3506, publicado como Informativo em março de 2003, procurou uma gramática comum para pontos, cupons, vales-presente, bilhetes, cartões telefônicos e notas de entrega. Não tratou tudo como dinheiro. Tratou cada item como representação digital de um direito de reivindicar bens ou serviços.

O modelo escolheu três elementos. I representa o emissor, P a promessa e H o titular. O voucher é <I,P,H>. A promessa pode oferecer desconto, acesso temporário ou um produto específico, e pode ser descrita em linguagem natural ou XML. Descrever a promessa, porém, não determina se uma instância ainda existe nem quem pode resgatá-la.

Quatro participantes receberam funções limitadas. O emissor cria e garante o conteúdo. O titular possui, transfere e resgata. O coletor examina e cumpre a promessa. O provedor VTS mantém a exclusividade, impedindo que uma instância seja atribuída a vários titulares ou usada mais vezes do que suas regras permitem.

O ponto comum é o Valid Voucher Set, VVS. Trata-se de um conjunto lógico de triplas válidas, inicialmente vazio. Ele não exige banco central. Pode ser implementado em cartões distribuídos, servidores de emissores ou terceiros confiáveis. O RFC padronizou a relação que precisava permanecer verdadeira, não a instituição que deveria guardar todos os dados.

Emitir cria a tripla e a adiciona ao VVS com intenção do emissor. Transferir reescreve <I,P,H> como <I,P,H'> com intenção do titular original. Arquivos antigos podem continuar no correio ou em cópias de segurança, mas não continuam titulares. O direito muda porque o estado válido muda.

O resgate se divide em apresentação e consumo. Apresentar mostra a tripla e preserva a propriedade, como uma licença reutilizável. Consumir remove a tripla, anula o direito ou reduz o número restante de usos, como um bilhete ou cartão de chamadas. A mesma etiqueta “usado” não poderia representar honestamente os dois casos.

Os requisitos de segurança refletem essa estrutura. Só o emissor pode criar uma instância válida. Só o titular atual inicia transferência ou resgate. A única alteração permitida na circulação é a troca autorizada de titular. Um voucher consumido não volta a ser resgatável e uma instância não deve possuir dois titulares válidos ao mesmo tempo.

Assinar o arquivo não basta. Para um voucher intransferível, a assinatura do emissor sobre I, P e H pode ser adequada. Quando H muda, a assinatura original se rompe. E impedir resgate duplicado ainda requer consulta de estado ou dispositivo resistente a adulteração. Autenticidade documental e exclusividade operacional são comprovantes diferentes.

O RFC também equilibrou privacidade e confiança. Titulares atuais e anteriores deveriam ficar ocultos de quem recebesse o voucher, enquanto o sistema ainda precisava ajudar o usuário a avaliar o emissor e a autenticidade. Manter evidência suficiente para recusar duplicação não autoriza divulgar todo o percurso da pessoa.

Um corretor global único também não era pressuposto. A falha de uma organização central derrubaria tudo. Ainda assim, RFC 3506 não exigiu uma tecnologia descentralizada específica. Sistemas off-line de alta velocidade e serviços on-line tinham custos diferentes. Um único protocolo de transferência foi considerado impraticável naquele estágio.

A separação abriu espaço para protocolo de transferência, API VTS e Generic Voucher Language. O significado mínimo podia ficar estável enquanto várias implementações buscavam desempenho, simplicidade e confiança por caminhos distintos.

RFC 4153 definiu depois o Voucher Component XML. Ele informa valor, mercadoria, restrições, emissor e provedor. E declara que o componente não é um voucher: várias instâncias podem compartilhar a mesma descrição. Duplicar XML não multiplica direitos.

O componente é raiz de confiança e deve ser protegido contra alteração. Canal seguro ou assinatura de objeto protege a promessa. Mas titularidade, prevenção de reprodução e resgate duplicado ficam normalmente fora do componente. Documento íntegro não é saldo atual.

RFC 4154 ofereceu uma API uniforme. Emissão adiciona, transferência retira do remetente e entrega ao receptor, consumo remove, apresentação preserva. A interface reduz dependência da implementação, mas não cria a autoridade que solicita nem o compromisso que confirma.

A observação do IESG advertiu que a API supunha um plug-in VTS confiável e não definia autenticação da aplicação. Era necessária proteção adicional. Portanto, uma função bem chamada não prova autorização, e seu retorno não prova que o coletor entregou o produto ou serviço.

A cadeia de evidência começa na descrição, passa por confiança no emissor e provedor, instância no VVS, autenticação do titular, autorização, confirmação da transição, aceitação do coletor e entrega real. Cada etapa tem dono e falha próprios.

Os vouchers usados mais tarde para integrar dispositivos pertencem a outra família técnica. O nome compartilhado não une os modelos. Da mesma forma, a publicação Informativa não comprova adoção comercial, interoperabilidade ou resultado. Esses fatos precisam de execução observável.

O mérito histórico de RFC 3506 foi impedir que a facilidade de copiar informação destruísse a noção de direito exclusivo. O arquivo explica. A assinatura protege uma afirmação. A API pede. O conjunto válido decide quem ainda pode reivindicar. E somente o coletor transforma o estado em benefício real.

Sources