Resumo

  • A RFC 3505 definiu requisitos para uma hierarquia comum de campos de comércio eletrônico, reduzindo adivinhações entre carteiras, formulários e sistemas de retaguarda.
  • Ela não substituía TLS, SET, EMV, XML ou IOTP: reconhecer o nome de um dado não autenticava o comerciante, não autorizava sua divulgação e não comprovava pagamento, liquidação ou entrega.

O atrito no início do comércio eletrônico parecia banal. Uma loja chamava o sobrenome de “surname”, outra de last_name, e uma terceira escondia o mesmo dado em uma árvore proprietária. Uma pessoa conseguia ler o rótulo e digitar tudo outra vez. Uma carteira de software não sabia, com segurança, qual caixa correspondia a qual informação.

Publicada em março de 2003 como documento Informational, a RFC 3505 tratou esse atrito como problema de interoperabilidade. A segunda versão da ECML deveria organizar objetos de processamento de pagamentos em uma hierarquia comum, atender relações entre consumidor e comerciante e também entre empresas, e ampliar o trabalho anterior de formulários HTML para XML, novos meios de pagamento e sistemas de retaguarda.

O escopo incluía custo, recibo, moeda, cartão, pagamento e dados bancários ou de telecomunicações; incluía ainda cheque eletrônico, ACH, pagamentos por celular e PDA, cartões de compra e carteiras empresariais. Ao mesmo tempo, o princípio de desenho era contido: preservar a versão 1.1, acrescentar o mínimo necessário e aproveitar a arquitetura mais ampla da Web, com URIs, camadas e extensibilidade.

Tratava-se de um contrato de vocabulário. Se a carteira reconhecesse o nome estruturado da cidade de entrega, poderia oferecer o valor sem tentar decifrar um rótulo humano. Se o sistema de retaguarda entendesse a mesma hierarquia, poderia mapear o conceito para sua própria operação. Nomes comuns reduziam o custo de tradução; não colocavam sistemas independentes dentro do mesmo domínio de confiança.

A própria RFC recusava essa confusão. ECML v2 não era alternativa a TLS, SET, EMV, XML ou IOTP. Essas tecnologias ofereciam capacidades diferentes: confidencialidade do canal, transações não repudiáveis, escolha do esquema, cartões inteligentes ou fluxo comercial. A ECML nomeava dados. Não incorporava todos os controles em torno deles.

Essa fronteira importava porque os campos eram sensíveis. Nome, endereço, identificador de conta, cartão e credenciais poderiam ser liberados em escala maior quando uma carteira os entendesse automaticamente. Por isso, a RFC 3505 tornou a proteção dependente da infraestrutura de transmissão e dos aplicativos que guardavam ou soltavam a informação. O vocabulário não precisava inventar criptografia, mas a especificação precisava alertar quem implementava.

Uma estrutura bem formada continuava sendo evidência limitada. DTD, possível schema, exemplos XML testados e comparação com vocabulários anteriores demonstravam conformidade de nomes e estrutura. Não demonstravam que o cartão pertencia ao usuário, que o preço era honesto, que a página vinha do comerciante legítimo ou que o processador autorizara a cobrança.

O pedido por um campo oculto de tradução expunha o problema da migração. Ele poderia mapear campos ECML aos campos antigos de um comerciante e permitir adoção sem reescrever o sistema. Isso diminuía custo, mas fazia dados sensíveis atravessarem correspondências invisíveis ao usuário. Compatibilidade resolvia como entregar; não decidia se a entrega tinha consentimento.

A RFC 4112 publicou a especificação da ECML v2 em 2005. Ela definiu nomes hierárquicos e apresentou XML como sintaxe exemplar, sem impedir outras codificações e protocolos. A conformidade restringia nomes e hierarquia no fio, não o rótulo visível. Uma loja podia exibir português enquanto preservava a semântica comum para as máquinas.

Os valores MIN da tabela eram obrigações de capacidade: o formulário precisava aceitar pelo menos certo tamanho. Eles não eram testes de validade. Um nome, telefone ou endereço fora de uma faixa intuitiva ainda podia ser legítimo. Transformar capacidade em prova de identidade faria de um piso de interoperabilidade uma regra falsa sobre pessoas reais.

Os modos query e assert descreviam a intenção da mensagem. Um solicitava valor; o outro fornecia valor. O nome do campo dizia o que foi pedido ou afirmado, mas não autenticava quem perguntou nem tornava verdadeira a resposta. Antes de preencher, a carteira ainda precisava de uma política separada para avaliar contraparte, finalidade e momento.

Na Web, Ecom_SchemaVersion indicava qual conjunto de campos estava presente e permitia escolher a interpretação correta. Era obrigatório nas transações ECML para Web, mas não identificava o comerciante, não validava a página e não protegia o canal. Reconhecer versão não era autenticar destino.

Formulários de várias páginas traziam outro risco: o preenchimento automático podia continuar liberando dados depois de a interação comercial ter terminado. Ecom_TransactionComplete era um aviso para interromper a automação até nova autorização. Ele limitava divulgação; não era recibo de pagamento e não provava autorização, captura, liquidação, cumprimento ou aceitação do comprador.

A seção de segurança manteve dependências externas explícitas. Informação sensível exigia confidencialidade e proteção contra alteração. Autenticidade poderia usar segurança de objeto, como assinaturas XML ou CMS, ou segurança de canal, como TLS ou IPsec. A especificação indicava opções, sem definir uma defesa universal.

O controle do usuário permanecia indispensável. Terminais compartilhados deveriam permitir desativar a memória de dados pessoais, informação armazenada precisava de proteção e valores ocultos ou padrão podiam ser alterados maliciosamente antes do retorno. Estrutura previsível não tornava benigno o aplicativo ao redor.

Uma escada honesta de recibos começa com “campo reconhecido”. Depois vêm validade estrutural, contraparte autenticada, divulgação autorizada pelo usuário, transmissão protegida, aceitação pelo aplicativo, autorização do pagamento, compensação ou liquidação e, por fim, entrega. Saltar dos primeiros degraus para “pago” transforma legibilidade de máquina em afirmação comercial.

Publicação de uma RFC também não prova implantação. A RFC 3505 registrou requisitos e a RFC 4112 depois publicou uma especificação Standards Track. Nenhuma das duas, sozinha, prova adoção por navegadores, uso por carteiras, interoperabilidade entre lojas, resultado de privacidade ou transação bem-sucedida. Isso exige evidência operacional.

A contribuição estreita da ECML ainda era relevante. Ela removeu uma forma de atrito sem fingir resolver todas as camadas. Nomes comuns são uma capacidade. Saber se essa capacidade foi autorizada, protegida e convertida em resultado econômico completo continua sendo decisão de outros atores, comprovada por outros recibos.

Fontes