Resumo

  • O overview revisão 02 e o core revisão 04 do vCon continuam sendo Internet-Drafts em elaboração. O criador delimita a conversa e pode omitir qualquer uma das quatro partes principais do contêiner.
  • JWS pode provar a integridade do payload e, conforme a política de confiança, a posse da chave. Não prova sozinho que todas as falas foram capturadas, que uma pessoa foi identificada, que o consentimento vale hoje ou que uma análise está correta.
  • A cadeia de amended preserva estados assinados sucessivos. Para decidir, o receptor também precisa de um livro de evidências que ligue cada alegação à fonte, ao escopo, à finalidade e à autoridade responsável.

Um pacote chega à auditoria com uma sequência impecável à primeira vista. A primeira versão guarda a gravação; a segunda acrescenta uma transcrição; a terceira troca o apelido de uma conta pelo nome de uma pessoa e inclui sentimento. Todas as assinaturas passam. O content_hash de um áudio externo confere. Cada sucessora aponta para o UUID anterior.

A confiança começa a se desfazer sem que nenhum bit falhe. Uma faixa de áudio retorna 403. Quem corrigiu a identidade foi o fornecedor de transcrição, não o sistema que autenticou o usuário. O campo vendor identifica o produtor do sentimento, mas não há modelo, idioma nem configuração. O registro de consentimento menciona gravação e qualidade, não avaliação de trabalhadores.

O que a criptografia comprovou continua verdadeiro: determinados domínios se comprometeram com determinados bytes. O que ela não resolveu é se esses bytes contam a história completa e se cada domínio podia transformar a história daquele modo.

draft-ietf-vcon-overview-02, datado de 30 de setembro de 2026, e draft-ietf-vcon-vcon-core-04, de 7 de setembro, são trabalhos do grupo Virtualized Conversations do IETF. Permanecem Internet-Drafts, não RFCs ou padrões concluídos. A proposta de um contêiner JSON interoperável é útil justamente porque conversas passam por plataformas, analistas e domínios de segurança. Essa mobilidade exige que o destinatário decomponha a palavra “verificado”.

Cinco verificações que não cabem em um único selo

Integridade pergunta se o payload é o mesmo que foi assinado. Autenticação do signatário pergunta que identidade a chave e a cadeia de certificados realmente estabelecem. Proveniência de captura pergunta qual sistema observou ou transformou cada item. Verdade semântica confronta nomes, horários, transcrições e inferências com o mundo. Autoridade decide se o ator podia coletar, modificar, compartilhar ou usar o dado para aquela finalidade.

JWS responde diretamente à primeira pergunta e ajuda na segunda. A estrutura do vCon pode transportar evidência para a terceira. As duas últimas são decisões externas ao payload. Uma afirmação falsa pode ter uma assinatura válida; uma afirmação verdadeira pode ter sido usada sem permissão.

Por isso, “conversa verificada” é um estado ruim. A operação deve exibir separadamente integridade válida, cadeia aceita, cobertura desconhecida, identidade pendente e finalidade negada. Precisão de linguagem é um controle de autorização.

O criador também edita as fronteiras da conversa

O overview reconhece que uma conversa não tem sempre começo e fim naturais. Um vCon pode representar uma única gravação ou uma jornada de mensagem, chamada e e-mail. Em SMS, alguém precisa decidir quais mensagens pertencem à mesma conversa.

As quatro áreas — parties, dialog, attachments e analysis — são opcionais. Uma gravação sem partes identificadas pode ser válida. O core permite recording, recording-set, text, transfer, incomplete e objetos de placeholder. Uma gravação pode conter apenas uma perna ou subconjunto dos canais, sem listar todos os participantes.

Essa flexibilidade favorece minimização e implantação gradual. Também torna impossível deduzir completude da conformidade. Uma ausência pode proteger privacidade, refletir uma pane ou selecionar conveniências. A assinatura congela o recorte, não prova que nada relevante ficou de fora.

O receptor deve guardar uma declaração de escopo: início e fim, canais, transferências, sistemas de origem, lacunas conhecidas, política de captura e responsável por definir o conjunto. Eventos de controle, IDs de mensagens, saúde dos gravadores e logs de outro domínio podem corroborá-la.

O overview chama o diálogo de “ground truths”. Isso o diferencia de uma análise derivada; não transforma um sensor parcial em observador onisciente. Um áudio autêntico pode não conter o trecho decisivo.

Atributos de uma parte não equivalem à identidade da pessoa

Um Party Object pode ter nome, telefone, e-mail, SIP URI, DID, UUID e localização. validation registra como a identidade foi verificada sem expor a evidência de verificação. A separação protege dados sensíveis, mas deixa a avaliação para quem recebe.

Uma assinatura sobre “validado por credenciais” mostra quem assumiu essa declaração. Não mostra quais credenciais, quando foram checadas, em que nível, nem se a conta ainda pertence à mesma pessoa. Cada alegação usada deve ser ligada ao evento, fonte, horário, nível de garantia e domínio responsável.

O UUID persistente também depende de namespace. Ele correlaciona um agente dentro de um operador, mas não vira identidade universal ao viajar. Se uma versão posterior substitui alias por nome civil, verifique se o novo signatário tinha autoridade sobre identidade, não apenas uma chave válida.

O hash pode sobreviver ao objeto que deveria proteger

Diálogo, anexo e análise podem vir inline ou por URL HTTPS. content_hash, com SHA-512, permite comparar os bytes obtidos com o compromisso dentro do contêiner assinado.

O core deixa fora de escopo armazenamento seguro, acesso e troca de credenciais para o conteúdo externo. Uma URL pode responder 403, 404 ou expirar. A retenção pode apagar o arquivo. O hash permanece exato mesmo quando ninguém consegue examinar a evidência.

São necessários três estados: referência assinada íntegra, conteúdo disponível e uso autorizado. Segurança do arquivo, decodificação e cobertura temporal continuam separados.

Para auditoria longa, conservar apenas o vCon e o hash mantém a promessa de que certos bytes existiram, não a capacidade de analisá-los outra vez. A liderança deve optar por arquivar os bytes, garantir acesso controlado duradouro ou declarar a expiração probatória.

Proveniência de análise não é precisão de análise

O Analysis Object comporta transcrição, tradução, resumo, sentimento e relatório. O core evita padronizar todos os formatos, exige vendor e aceita product e schema. O overview reconhece que implementações variam em qualidade e interpretação.

Esses campos identificam origem e formato, mas podem não revelar modelo, prompt, locale, limiar, pré-processamento, entradas ou edição humana. Um sentimento pode ser autenticamente produzido pelo fornecedor e ainda ser errado ou inadequado para uma decisão sobre alguém.

Cada derivação merece seu recibo: índices e hashes de entrada, vendor, product, schema, versão de modelo ou regra, configuração, locale, hash de saída, semântica de confiança, revisão humana e finalidade. Esse livro de evidências é uma proposta de Daniel Kade, não uma exigência normativa dos drafts.

Assinar o resultado preserva o que o sistema produziu. Não converte procedência em qualidade, nem qualidade em autorização.

Consentimento tem finalidade, jurisdição e tempo

O overview trata consentimento e proveniência como contexto. O privacy primer e o draft de lawful basis examinam aviso, finalidade e jurisdição. Eles não tornam a assinatura um certificado universal de licitude.

Uma alegação de consentimento deve identificar pessoa, método, momento, versão da política, usos descritos, jurisdição e retirada. Captura, análise, divulgação e retenção podem ter bases diferentes; a base pode nem ser consentimento. Este artigo não oferece aconselhamento jurídico, mas exige que o sistema preserve evidência para a decisão local.

A assinatura autentica que alguém registrou aquela alegação naquele estado. O receptor ainda decide se o ator podia fazê-la, se cobre a finalidade atual e quais ações uma retirada exige.

Se o consentimento mudar amanhã, a assinatura de ontem não deve deixar de ser válida: ela é história. O que muda é a autorização presente para processar e distribuir.

Emendas guardam uma sequência; não escolhem a versão verdadeira

Modificar um vCon assinado quebra sua assinatura. Os drafts criam então uma nova instance version, cópia profunda da anterior com adições ou correções, ligada por amended ao UUID predecessor e, opcionalmente, à sua URL e hash. Domínios diferentes podem assinar etapas sucessivas.

A cadeia preserva compromissos. Não prova que a cópia manteve tudo, que os índices continuam equivalentes, que a correção está certa ou que o novo signatário podia fazê-la. O receptor precisa recuperar e verificar o predecessor, comparar objetos e autorizar cada classe de mudança.

Redação evidencia o mesmo limite. O core deixa o método de redaction fora de escopo e atribui a garantia à entidade que cria e assina a versão. Ela pode assinar honestamente e esquecer dados em attachment, analysis ou extensão desconhecida.

Nunca use “versão assinada mais recente” como sinônimo de “versão autoritativa”. Um analista pode acrescentar transcript sem poder reidentificar uma parte. Um domínio pode ocultar dados para certo público sem ter permissão para destruir a fonte.

Extensão desconhecida muda de risco conforme a operação

Extensões podem adicionar campos, redefinir semântica ou depreciar parâmetros. As incompatíveis entram em critical; um processador sem suporte deve rejeitar ou relatar, não continuar.

A compatibilidade é contextual. Um transcritor pode ignorar um campo novo. Um redator pode precisar compreender todos os campos capazes de guardar informação pessoal. O mesmo vCon pode ser aceitável para uma tarefa e proibido para outra.

Registre extensões, critical, versões do registry e do processador, operação e justificativa para ignorar ou bloquear. JSON bem formado não é sinônimo de semântica compreendida.

O livro de evidências fica ao lado do contêiner

Para cada dependência, ligue UUID, hash e forma do vCon; escopo e exclusões; sistemas e domínios contribuintes; signatário, certificado e política; evidência das partes; cobertura; acesso externo; entradas e configuração da análise; autoridade de finalidade; capacidade de extensões; predecessor, diferenças; decisão, dono e reversão.

Separe observação de alegação. “SHA-512 dos bytes recuperados confere” é observado. “Identidade validada por credenciais” continua sendo declaração do payload até apontar para o evento. “Uso permitido para qualidade até a data X” é decisão local.

A sequência é escopo -> recuperar -> verificar bytes -> identificar signatário -> autorizar alegações -> inspecionar extensões -> reconstruir linhagem -> validar claims -> autorizar finalidade -> registrar dependência -> monitorar retirada.

No caso inicial, as assinaturas continuam válidas. A decisão que requer completude espera a faixa ausente. A mudança de identidade fica em quarentena. O sentimento pode ser armazenado, mas não decide. O consentimento histórico permanece autêntico e a nova finalidade requer nova decisão.