Resumo

  • A RFC 3504 reparou três superfícies executáveis do IOTP v1: a DTD, a continuidade da transação depois da autenticação e a lista de conteúdos identificáveis por uma assinatura IOTP.
  • Aplicar a errata demonstrava alinhamento com a especificação corrigida, não sucesso da autenticação, autoridade do signatário, autorização da cobrança, liquidação, entrega, implantação ou adoção.

Em prosa comum, trocar “reiniciada” por “continuada” parece edição. Numa máquina de estados, a palavra decide se o sistema preserva o contexto comercial que chegou a uma etapa de autenticação ou age como se a troca começasse de novo.

Publicada em março de 2003 como documento Informational, a RFC 3504 reuniu erros descobertos depois das especificações do IOTP versão 1, especialmente a extensa RFC 2801. O IOTP era um arcabouço comercial independente do sistema de pagamento; loja, processador, entrega e atendimento podiam pertencer a organizações diferentes.

Essa distribuição tornava decisivo o sentido comum. Ao atravessar limites empresariais, uma mensagem precisava conservar a transação e o ato que representava. Divergência de gramática ou estado podia alterar o comportamento de outra organização que alegava implementar a mesma RFC.

A primeira correção tratava de PackagedContent. A DTD havia trocado os tipos de Name e Content. A errata tornou Name um NMTOKEN e Content um CDATA. Esse recipiente aparecia em desafios de autenticação, pedidos, marcas, dados de esquema de pagamento, recibos e entrega.

Código gerado da declaração antiga podia impor restrição léxica ao valor errado. Um produtor emitiria algo aceito localmente e recusado pelo par. “Suporta RFC 2801” escondia a pergunta sobre qual edição da gramática estava em execução.

O segundo reparo era mínimo: o elemento Attribute usava ( ANY ), forma inválida, em vez de ANY. Um validador não pode adivinhar normativamente a intenção. Sem correção comum, equipes poderiam aplicar remendos diferentes, abandonar validação ou criar exceções incompatíveis.

Passar pela DTD corrigida continuava sendo recibo estrutural. Provava nomes, classes e organização, não a veracidade dos dados, a autoridade da contraparte ou a movimentação de dinheiro.

O terceiro reparo atingia o estado. Ao combinar autenticação com outra transação IOTP, o texto dizia que a transação original seria reiniciada após sucesso. A RFC 3504 mudou para continuada.

A identidade, então, atravessava a porta. Autenticação era condição dentro do intercâmbio maior, não criadora de uma segunda compra. Identificador, componentes acumulados, registros de idempotência e escopo de autorização permaneciam ligados ao contexto original.

“Continuada” não informava que a autenticação ocorrera. Definia a consequência caso fosse bem-sucedida. Ainda era necessária uma decisão vinculada a ator, método, desafio, resposta e transação. Identidade autenticada também não autorizava automaticamente pagamento ou entrega.

A lista de tipos de assinatura tinha outra lacuna. Ela cobria respostas de oferta, pagamento e entrega, autenticação e ping, mas omitia AuthenticationStatus, InquiryRequest e InquiryResponse. A RFC 3504 acrescentou os três e permitiu seu uso por qualquer papel.

Um verificador preso à lista antiga podia rejeitar tipo permitido; um verificador permissivo podia aceitar sem regra compartilhada. Reconhecer tipo, porém, não verificava assinatura. Verificar assinatura tampouco demonstrava autoridade comercial, liquidação bancária ou entrega.

A RFC afirmou que os erros não eram especialmente de segurança e advertiu que implementações incorretas causadas por erros sem correção poderiam comprometê-la. Não era uma falha de algoritmo criptográfico; eram gramática, transição e despacho sustentando decisões sensíveis.

Por isso, errata pode ser dependência executável. O inventário precisa registrar documento base, correções aplicadas, artefato de parser ou schema e testes. Duas alegações de conformidade com o mesmo número podem descrever máquinas diferentes.

Até os metadados mostram a fronteira. O cabeçalho da RFC 3504 não declara Updates: 2801; a errata 2947 do RFC Editor, mantida para atualização documental, afirma que deveria declarar porque as mudanças são normativas. O texto já mudava execução enquanto a relação editorial não exprimia toda a força.

A cadeia honesta começa em edição e conjunto de erratas, segue por construção reproduzível, documento aceito, identidade preservada, decisão de autenticação, tipo reconhecido, assinatura verificada, ato autorizado e recibo externo de pagamento ou entrega.

Gramática responde se a mensagem é interpretável; continuidade, qual contexto sobrevive; tipo, o que a assinatura pretende cobrir. Nenhum desses recibos equivale à compra paga e cumprida.

Fontes