O que deve constar na página de verificação QR do relatório?

Resposta breve: qual é a função da página de verificação?

A página deve mostrar a identidade do relatório, a revisão atual, o estado de publicação, o resultado da assinatura e da integridade, a hora da verificação; não deve expor publicamente dados pessoais desnecessários nem o conteúdo integral do relatório.

O código QR é apenas um transportador que leva ao endereço correto. O que cria a confiança é a página aberta corresponder em tempo real ao registo canónico do relatório, não considerar válido um resultado ambíguo e explicar claramente ao utilizador o que foi verificado.

Que informações são obrigatórias na página de verificação?

Resposta breve: o utilizador deve ver primeiro o resultado e, em seguida, para que relatório e versão se chegou a esse resultado. Os detalhes técnicos devem explicar o resultado, sem ofuscar a mensagem principal.

A explicação de assinatura eletrónica do BTK indica que a assinatura eletrónica segura permite identificar o signatário e perceber se os dados assinados foram alterados posteriormente. Por isso, “registo encontrado” e “assinatura e integridade do conteúdo verificadas” não são o mesmo estado.

Como separar válido, inválido e não verificável?

Os três estados devem ser separados por linhas claras. Um erro de serviço ou evidência em falta não é uma verificação bem-sucedida.

• Válido: A versão pedida do relatório foi encontrada, o estado de publicação é adequado, e os controlos de assinatura e integridade foram concluídos com sucesso segundo a política definida.
• Inválido: O conteúdo foi alterado, a assinatura falhou criptograficamente ou o registo está explicitamente anulado/inválido.
• Não verificável: Não foi possível obter o estado do certificado, o serviço de verificação não respondeu, falta evidência ou não foi possível produzir uma decisão sobre a integridade do registo.

A ETSI TS 119 102-2 prevê, no relatório de verificação, um rasto estruturado do resultado com o verificador e os objetos de verificação utilizados. A correspondência técnica na implementação da VizyonTech é mostrar ao utilizador final um resultado simples, mas preservar no registo de auditoria as referências ao verificador, à política/versão e à evidência técnica associadas ao resultado.

Num ecrã de erro inesperado não devem ser mostrados rastos de pilha, identificadores de base de dados, cadeias de certificados ou nomes de serviços internos. De acordo com a abordagem deny-by-default da OWASP, quando o sistema falha, o resultado deve permanecer “não verificável” e deve ser fornecido ao utilizador uma referência segura de apoio.

Com que nível de detalhe deve ser mostrado o resultado da assinatura eletrónica?

Resposta breve: em vez de um selo que emita juízos jurídicos, deve mostrar-se um resumo simples e verificável dos controlos técnicos efetuados.

A existência da assinatura não significa, por si só, que o relatório está atualizado ou operacionalmente autorizado. O ecrã deve, no mínimo, distinguir o resultado da integridade da assinatura, a hora da assinatura, a hora de verificação do certificado e, se existir, o resultado do carimbo temporal. Se a identidade do signatário for mostrada, devem usar-se apenas os campos necessários para a verificação.

O artigo 32.º do eIDAS trata, como condições separadas, controlos como a natureza e validade do certificado no momento da assinatura, os dados de verificação da assinatura, os dados do signatário e a deteção de problemas relacionados com a segurança. Na prática turca, a legislação em vigor e a política da organização devem ser avaliadas adicionalmente; a página não deve produzir, a partir do controlo técnico apenas, uma alegação de certeza jurídica fora do âmbito.

Para conceber o fluxo do relatório antes da assinatura pode consultar o guia de fluxo de trabalho de assinatura eletrónica em relatórios de inspeção A página QR é a face controlada de verificação dessa cadeia, aberta ao utilizador externo.

Que informações não devem ser públicas?

Resposta breve: não mostre na página pública detalhes pessoais, comerciais e técnicos desnecessários à verificação; transfira o relatório detalhado para acesso autorizado.

Os princípios fundamentais da KVKK exigem que o processamento de dados pessoais seja relacionado com a finalidade, limitado e proporcional. Deve assumir-se que a ligação QR pode ser partilhada por terceiros; a vista pública deve ser concebida em função desse risco.

• Não mostre dados pessoais diretos como número de identidade, endereço, telefone e e-mail.
• Não publique a imagem da assinatura manuscrita, detalhes desnecessários do certificado e o número de série completo.
• Não abra por predefinição os dados confidenciais de instalações do cliente, os anexos de medição e o PDF integral do relatório.
• Se o nome do signatário não for obrigatório, utilize a função ou um nome mascarado; documente a obrigatoriedade com a finalidade do processamento de dados.
• Proteja a transferência detalhada de ficheiros com autenticação, autorização e registo de ações.

Como mostrar a informação de revisão e cancelamento?

Em vez de eliminar silenciosamente o relatório antigo, declare claramente o seu estado e forneça uma ligação segura para a versão atual. Assim, os PDF antigos distribuídos podem ser verificados retrospetivamente.

Os estados “atual”, “foi publicada nova revisão”, “cancelado” e “aguarda publicação” devem ser distintos. Se o motivo do cancelamento contiver informação sensível, deve mostrar-se apenas a classe geral; o detalhe fica reservado ao utilizador autorizado. A nova revisão não deve sobrescrever o URL ou o histórico do registo antigo; a relação entre os dois registos deve ser preservada no rasto de auditoria.

Como deve ser a experiência de verificação móvel e acessível?

O resultado deve compreender-se num único ecrã, rapidamente e sem depender apenas da cor. Como o QR será sobretudo aberto a partir do telemóvel, a primeira vista deve mostrar juntos a identidade do relatório e o resultado.

• Apresente o estado com texto, ícone e contraste suficiente em conjunto.
• Comunique as alterações de estado às tecnologias de apoio com uma região ativa adequada ou um papel de estado.
• Mantenha os alvos de toque fáceis de selecionar; não obrigue a percorrer a tabela horizontalmente.
• Torne visível que a ligação está no verdadeiro domínio VizyonTech e em HTTPS.
• Se o QR não puder ser lido, ofereça uma consulta alternativa com o número do relatório e um código seguro de verificação.

O WCAG 2.2 exige alternativas em texto, conteúdo compreensível e que as mensagens de estado sejam determináveis programaticamente. Por isso, a cor verde/vermelha ou o visto/cruz, por si sós, não chegam.

Como pilotar o fluxo de verificação da VizyonTech?

Ao avaliar a solução Vizyon Periyodik ao avaliar, teste com exemplos realistas mas anonimizados, pelo menos os seguintes cenários: relatório atual e válido, revisão antiga, registo cancelado, ficheiro alterado, tempo limite do serviço de verificação e acesso não autorizado ao relatório completo.

A medida de sucesso não é apenas o QR abrir. O utilizador percebe que relatório verificou? Perante um estado ambíguo, o sistema mantém-se fechado? Há fuga de dados desnecessários? O resultado é legível no ecrã móvel? E a equipa de apoio consegue seguir o incidente com o código de referência seguro? O piloto deve produzir evidência para estas perguntas.