Summary

  • A revisão 12 de Vaara Receipt pode assinar seq e runningCount dentro de uma boundary; quando um registro posterior existe, a retirada de um recibo intermediário vira uma lacuna verificável.
  • Um prefixo contínuo continua ambíguo. O sealing record fixa o total N, mas a remoção do sufixo junto com o próprio selo deixa o conjunto guardado internamente consistente.
  • O draft usa uma âncora RFC 3161 sobre a contagem final para externalizar esse fato. Integridade, cobertura, completude interna, fechamento, custódia temporal e resultado não são o mesmo recibo.

O conjunto que fecha cedo demais

Considere uma fronteira que emite um recibo para cada decisão de um agente. Se o item 7 for retirado, mas o 8 continuar presente, o runningCount posterior denuncia a falta. Há uma expectativa assinada de nove itens e apenas oito aparecem.

Agora retire 8, 9 e todos os registros seguintes. O item 7 declara corretamente que oito recibos existiam até aquele instante. O auditor recebe oito, sem saltos. Não há byte inconsistente. O erro está em transformar “este prefixo está inteiro” em “esta história terminou aqui”.

draft-sirkkavaara-vaara-receipt-12 separa esses dois enunciados. A proposta fornece uma forma de provar buracos internos e descreve o que ainda precisa sair do conjunto local para provar o encerramento.

A boundary define o que pode ser contado

O bloco opcional coverage identifica o chokepoint, a superfície exata de ferramentas ou comandos e a regra de que apenas chamadas roteadas por ali são observadas. Um caminho direto ou outro gateway não vira coberto só porque os recibos existentes são válidos.

Por isso, ausência de recusa não prova ausência de ação. Com coverage, significa no máximo “não recusada dentro desta boundary”. Sem coverage, significa apenas que o conjunto não a observou. Antes de perguntar quantos recibos existem, é preciso perguntar qual universo o emissor conseguia ver.

O bloco completeness acrescenta boundaryId, um seq monotônico iniciado em zero e runningCount = seq + 1. O registro posterior amarra a expectativa sobre os anteriores. Essa é uma melhoria concreta de governança: a exclusão no meio deixa de depender da palavra do emissor.

Selar não elimina a questão de custódia

O terminal sealing record declara {sealed: true, total: N}. Quando esse objeto está disponível, o auditor sabe que o conjunto deve chegar a N. Um maxClass opcional pode limitar a maior classe de ação autorizada dentro da boundary e, assim, o pior caso de um item ausente.

Só que o selo também pode ser omitido. Quem controla a apresentação do sufixo pode retirar decisões finais e o registro que anunciava o total. O prefixo anterior continua válido. A revisão reconhece que nenhum cálculo sobre esse held set revela sozinho o selo suprimido.

A camada seguinte é uma âncora RFC 3161 sobre a contagem final. Ela registra que, até o instante T, existia um payload assinado ligado a N recibos. Se mais tarde alguém oferece apenas k, surge uma divergência contra uma evidência mantida fora do prefixo.

O formato do timestamp não resolve a independência institucional. Uma TSA administrada pela mesma equipe pode ser tecnicamente conforme e ainda compartilhar privilégios, retenção e incentivos com o produtor. O controle precisa nomear a autoridade, a política de validação, a chave, o relógio e o responsável pela guarda.

Transparência registra outra coisa

O draft também prevê registro em um serviço SCITT. O receipt do serviço compromete o Signed Statement aceito sob aquela política. Ele acompanha o Vaara receipt e não é apenas mais um item de timestampAnchors.

As propriedades não devem ser vendidas como um pacote indistinto. RFC 3161 trata de tempo sobre uma impressão. SCITT trata de registro transparente. runningCount encontra buracos antes de um item posterior. O seal fixa o total. RFC 9162 oferece o paralelo útil: prova de inclusão e prova de consistência continuam separadas mesmo em um log projetado para transparência.

Recomputar preserva a declaração

Com JCS, RFC 8785, implementações diferentes serializam o JSON para os mesmos bytes. Os vetores públicos e checkers independentes do código do emissor sustentam uma alegação relevante de running code: é possível recalcular assinatura, digest, back link e testes de contiguidade.

Isso não autentica a realidade descrita. O hash confirma qual evidência foi comprometida, não se ela era completa ou verdadeira. A assinatura confirma que uma chave produziu o payload, não que a chave continua válida. O próprio draft não define revogação nem freshness; cada deployment precisa explicitar resolução de chave e tolerância de atraso.

O recibo de decisão também não é o resultado. allow registra uma autorização. Um execution receipt pode voltar à decisão por backLink, declarar executed ou refused e comprometer o resultado. Ainda falta dizer quem observou o sistema externo e como a mudança foi reconciliada.

As camadas de realidade de Lu Heng evitam a falsa promoção: bytes canônicos não são história completa; história completa não é boundary fechada; seal não é testemunha independente; testemunha não é ação; ação não é efeito durável. Uma Minimum Initial Specification pode definir o envelope. As decisões futuras de cobertura e custódia continuam locais, e o running code comprova o mecanismo sem comprovar a operação do mundo.

Sources and limits

As fontes estabelecem uma Internet-Draft individual ativa e especificações públicas relacionadas. Não provam consenso IETF, RFC do Vaara Receipt, adoção por WG, auditoria independente, implantação ampla, cobertura total, independência da TSA nem resultado observado. Este Artigo cobre somente a fronteira da revisão 12 entre lacuna interna, cauda selada e âncora externa da contagem.