Resumo

  • A RFC 3354 exigia que o futuro IOTP v2 permitisse propor sequências arbitrárias de etapas comerciais, mas a proposta não autorizava o pagamento nem provava a execução das etapas.
  • Consentimento limitado para compras futuras, aviso de envio, autorização do sistema de pagamento, cobrança, liquidação e recibo para contestação permaneciam fatos independentes.

Uma transportadora informa que o produto saiu. O fluxo mostra uma cobrança logo depois. Essa vizinhança visual é perigosa: ela pode sugerir que o evento logístico já contém a permissão financeira. Não contém. Ainda é preciso saber quem afirmou o envio, quanto e quantas vezes o cliente autorizou, qual resposta veio do emissor e se os valores foram de fato capturados e liquidados.

Publicada em agosto de 2002 como documento Informational, a RFC 3354 registrou requisitos para uma segunda versão pretendida do Internet Open Trading Protocol. O IOTP v1 já estruturava o comércio eletrônico por papéis, blocos e mensagens. A proposta seguinte tentava preservar essa base sem limitar toda transação a um pagamento seguido por uma entrega. As partes deveriam poder propor uma sequência qualquer de passos.

O verbo essencial era “propor”. Um fluxo poderia começar com pedido de oferta, chamar um protocolo de pagamento externo no meio da negociação ou esperar um aviso de envio antes de solicitar pagamento. A sequência modelava dependências possíveis. Ela não concedia, por sua mera existência, consentimento do cliente ou poder de execução ao manipulador de pagamentos.

A RFC 3354 tampouco era a especificação pronta do IOTP v2. Separava funções obrigatórias, funções que poderiam ser incluídas e temas fora do escopo. O histórico do grupo TRADE da IETF marca como concluído o marco dos requisitos v2. Isso comprova a conclusão dos requisitos, não a entrega de protocolo, implementação ou implantação.

Entre as funções necessárias estavam sequência dinâmica, Offer Request Block, solução de problemas melhorada, papel mais claro de Customer Care, protocolos de pagamento não tunelados pelo IOTP e carteiras no servidor. Um cliente poderia apresentar um recibo assinado ao atendimento. O recibo sustentava uma contestação, mas não obrigava o atendente a aceitar a reclamação nem demonstrava poder para ressarcir.

A carteira no servidor também era apenas um local para funções delegadas. Sua presença não autenticava automaticamente o usuário atual nem ampliava um consentimento antigo. A possibilidade de usar pagamentos externos reconhecia outra fronteira: o IOTP podia coordenar a chamada, mas autenticação, autorização, recusa e liquidação continuavam pertencendo ao sistema de pagamento.

Pagamentos repetidos ou continuados apareciam somente na lista opcional. O exemplo previa autorização limitada: certo número de compras futuras, com teto total ou valor máximo por compra. Uma permissão operacional precisa declarar finalidade, beneficiário, moeda, limites, quantidade restante, expiração e revogação. A posição de um bloco no diagrama não fornece esses parâmetros.

Cada pedido posterior deve ser comparado à concessão. A compra pode respeitar o número de operações e exceder o limite unitário; pode caber no valor e chegar depois do vencimento; pode vir de comerciante ou finalidade diferente. A sequência agenda a decisão, mas não pode decidir a favor só porque o bloco de pagamento vem depois do consentimento.

O exemplo de envio revela a mesma separação. Mensagens ampliadas entre servidores poderiam permitir que um Delivery Handler avisasse a um Payment Handler que os bens haviam sido enviados. O aviso poderia ser uma condição para cobrar um cartão. Condição não é ordem. O registro prova apenas o que um agente identificado afirmou dentro do seu escopo autenticado.

Ele não prova entrega física, aceitação, autorização do emissor, captura ou liquidação. Uma implementação auditável preserva o aviso, a regra que o utilizou como pré-condição de uma solicitação específica e a resposta independente do sistema de pagamento. Se houver cobrança, captura e liquidação criam outros recibos. “O envio disparou o pagamento” é resumo de painel, não cadeia de evidências.

Os documentos próximos deixam as camadas mais nítidas. A RFC 2801 definiu as transações, funções, identificadores e processamento idempotente do IOTP v1. Resistir a mensagens duplicadas não cria autoridade para uma sequência nova. A RFC 2802 usou um manifesto para delimitar os componentes assinados. Uma assinatura válida autentica o material escolhido; não inventa consentimento.

A RFC 2935 transportou IOTP sobre HTTP, e a RFC 3106 padronizou nomes de campos de comércio eletrônico. Transporte e vocabulário compartilhado não validam conteúdo. A RFC 3275 ofereceu XML Signature; a RFC 2246 protegeu canais com TLS. A própria RFC 3354 dizia que IOTP não possuía confidencialidade e dependia de TLS ou IPsec, enquanto a proteção do pagamento dependia do sistema escolhido.

Logo, canal confidencial, conteúdo assinado, aprovação do cliente e autorização financeira são propriedades diferentes. Acrescentar campos e atributos a blocos também aumenta apenas a capacidade de expressão. Um campo chamado “aprovado” continua sendo afirmação até que produtor, assinatura, política, objeto e validade sejam conhecidos.

Questões legais e regulatórias ficavam fora do escopo. Conformidade técnica não demonstrava validade contratual, proteção do consumidor ou direito de cobrar numa jurisdição. Essa exclusão reconhecia que uma gramática universal não poderia concentrar todas as instituições que tornam uma decisão comercial legítima.

A RFC 3538 acrescentou SET ao contexto do IOTP v1. A RFC 3867 definiu mais tarde uma interface entre o núcleo IOTP e módulos de pagamento. Essa interface reforçou a distinção: orquestração e execução podiam produzir estados, erros e recibos separados. Nenhum dos dois textos prova que os requisitos v2 tenham se tornado implantação real.

O mérito histórico da RFC 3354 foi aumentar flexibilidade sem falsificar poder. Sequência era plano; aprovação futura era concessão limitada; aviso de envio era evidência de evento; assinatura cobria conteúdo determinado; TLS protegia o canal; o sistema de pagamento autorizava, executava e liquidava; Customer Care decidia o remédio depois.

O mesmo desenho aparece hoje quando um status de entrega libera fundos ou uma agenda de assinatura inicia débito. Quanto mais combinável for o processo, maior a necessidade de exigir autoridade no ponto irreversível. O protocolo podia propor qualquer caminho; o dinheiro ainda precisava de prova própria para atravessá-lo.

Sources