Polícia, Balcões de Aluguer, Empregadores, Seguradoras: Por Que Não Podem Ver os Mesmos Dados

O maior erro de design num futuro Permesso Internacional de Condução (PIC) seria tratar todos os verificadores como se fossem o mesmo. Um agente da polícia, um balcão de aluguer de automóveis, um empregador e uma seguradora não fazem a mesma pergunta — portanto, não devem receber a mesma resposta.

Um condutor. Um direito de conduzir subjacente. Uma carteira digital. Mas quatro verificadores muito diferentes:

• Um agente da polícia na berma da estrada
• Um balcão de aluguer de automóveis na entrega do veículo
• Um empregador a verificar a elegibilidade para conduzir a frota
• Uma seguradora a analisar uma participação de sinistro

Se o futuro PIC mostrar os mesmos dados a todos os quatro, o sistema já falhou. Não porque a credencial seja insegura, mas porque o modelo de divulgação é demasiado simples.

A comunidade de normalização já está a afastar-se desse modelo simples. O trabalho do W3C sobre credenciais verificáveis descreve o ecossistema em torno de emissores, titulares e verificadores, utilizando empregadores e sítios web como exemplos de verificadores. O trabalho europeu sobre a carta de condução digital (mDL) já trata as verificações na berma da estrada e os alugueres de automóveis como cenários de verificação distintos, incluindo a partilha remota antecipada para alugueres e verificações presenciais para a polícia. A arquitetura já foi concebida para múltiplos tipos de verificadores. O erro seria conceber a experiência do utilizador como se existisse apenas um tipo.

Por Que o Cartão Físico Nos Ensinou a Pensar de Forma Incorreta

Uma carta de condução física habituou-nos a uma abordagem de mostrar tudo. Entrega-se o cartão. A outra pessoa vê o que está no cartão. Essa é toda a interação.

Esta abordagem é aceitável num mundo em papel porque não existe alternativa. Torna-se inaceitável num mundo digital.

O W3C VC Data Model 2.0 afirma diretamente: uma carta de condução pode conter número de identificação, altura, peso, data de nascimento e morada — mas isso pode ainda ser muito mais do que o necessário para uma determinada transação. Pontos-chave das normas atuais:

• Boas práticas do W3C: suportar a divulgação seletiva e solicitar apenas o estritamente necessário
• Orientações europeias de proteção de dados: o tratamento deve ser limitado a finalidades especificadas, e os dados tratados devem ser necessários e proporcionais
• O primeiro princípio de um futuro PIC: a mesma credencial não significa o mesmo direito de consulta

O Modelo Correto É a Divulgação Baseada em Políticas

Para uma arquitetura séria, o modelo correto aproxima-se mais do controlo de acesso baseado em atributos do que da apresentação de um cartão digital.

A NIST SP 800-205 define as decisões de controlo de acesso como avaliações de atributos associados ao sujeito, ao objeto, à operação solicitada e às condições ambientais, confrontadas com uma política. Esta é exatamente a estrutura correta para um futuro PIC:

• Sujeito: o condutor
• Objeto: os campos de dados solicitados
• Ação: não “ver a carta” de forma abstrata, mas algo específico como “verificar o direito de conduzir veículos da categoria B na berma da estrada” ou “verificar a elegibilidade para aluguer relativa a uma reserva”
• Ambiente: berma da estrada, balcão de aluguer, pré-verificação remota, integração em frota e análise de sinistro pós-ocorrência são ambientes diferentes e devem conduzir a decisões diferentes

A NIST também refere que os sistemas de atributos necessitam de granularidade, governação e mecanismos de redução, agrupamento e minimização de atributos.

Assim, o futuro PIC não deve perguntar: Pode este verificador ler a carta? Deve perguntar: Que declarações pode este verificador receber, para que finalidade pretendida, neste ambiente e com que regras de retenção?

Um Verificador Deve Identificar-se Antes de Solicitar Qualquer Coisa

O futuro PIC não deve começar com a carteira digital a mostrar dados. Deve começar com o verificador a provar quem é.

A arquitetura EUDI é clara a este respeito. As partes requerentes devem:

• Registar os atributos que pretendem solicitar e para que finalidade
• Receber certificados de acesso
• Autenticar-se perante a carteira digital antes de qualquer divulgação
• Ser verificadas em relação ao âmbito registado, quando a informação de registo esteja disponível

O utilizador pode então ver quem está a solicitar, o que está a ser pedido e se o pedido se enquadra no âmbito registado.

O atual trabalho do ETSI sobre certificados para partes requerentes de carteiras digitais torna isto mais concreto. Um certificado de registo de parte requerente de carteira digital pode descrever a finalidade pretendida pela parte requerente e os atributos que registou para solicitar. O certificado de acesso associado existe para garantir que o pedido provém de uma parte legítima e autorizada. O ETSI inclui também metadados da parte requerente, tais como:

• Nome comercial
• URI de suporte
• Finalidade pretendida
• Autorizações
• URI de registo
• Informação sobre a autoridade de supervisão

O segundo princípio de um futuro PIC: sem identificação do verificador, sem divulgação.

Por Que os Ecrãs de Consentimento Não São Suficientes

Existe outro erro aqui: tratar a aprovação do utilizador como equivalente à legitimidade legal.

A arquitetura EUDI afirma explicitamente que a aprovação do utilizador para apresentar atributos não deve ser tratada como fundamento legal para o tratamento de dados pessoais pela parte requerente. A parte requerente deve ainda ter a sua própria base jurídica. O EUDI exige também a aprovação do utilizador em todos os casos de utilização, incluindo casos em que a parte requerente possa pertencer às forças de segurança ou a outra entidade governamental.

Uma boa interface de carteira digital pode ajudar, mas não consegue resolver por si só o excesso de recolha de dados pelo verificador. A regra tem de existir antes da interface.

Um futuro PIC necessita, portanto, de ambos:

• Autenticação criptográfica do verificador para confirmar quem está a solicitar
• Restrições de política sobre o que essa categoria de verificador pode solicitar

Sem ambos, a “escolha do utilizador” torna-se uma forma de transferir a falha de política para o indivíduo.

1. Polícia: Verificar o Direito de Conduzir, Não a Pessoa na Totalidade

O cenário de fiscalização policial na berma da estrada é o mais focado.

O manual da mDL da UE descreve-o diretamente: a polícia ou outros agentes verificam a carta de condução quando necessário, incluindo a validade da carta e as habilitações para o veículo. Na jornada do utilizador, o agente verifica a carta através de um fluxo ativado por QR code, Bluetooth, Wi-Fi Aware ou NFC. Trata-se de uma tarefa de verificação focada:

• Esta pessoa é o titular?
• A credencial é válida?
• Que habilitações e restrições de veículo se aplicam?

Permitido por defeito:

• Nome
• Fotografia
• Estado da carta de condução
• Datas de emissão e de validade
• Categorias
• Restrições relevantes para a condução
• Entidade emissora e jurisdição
• Resultado de atualidade/estado

Não permitido por defeito:

• Morada de residência
• Identificadores internos desnecessários para utilização na berma da estrada
• Atributos não relacionados provenientes de outras atestações
• Registos históricos de apresentação
• Metadados comerciais

As orientações de implementação da AAMVA reforçam o ponto relativo à fotografia: se a fotografia for solicitada e qualquer outro elemento for divulgado, a fotografia deve ser partilhada para que o verificador possa associar os dados à pessoa que os apresenta. As mesmas orientações referem também que as partes interessadas não devem rastrear os titulares de mDL nem a utilização da mDL, exceto quando exigido por lei.

O caso da polícia não se trata de o Estado receber tudo. Trata-se de o Estado receber os dados específicos de condução necessários para a fiscalização na berma da estrada. Esta é uma diferença importante.

2. Balcões de Aluguer: Elegibilidade, Correspondência de Identidade e Nada de Desnecessário

O caso do aluguer é mais detalhado porque existem realmente dois momentos: a pré-verificação remota antes da chegada e a entrega quando uma pessoa ou quiosque entrega as chaves.

O manual da mDL da UE já modela ambos. Um serviço de aluguer de automóveis pode solicitar a mDL juntamente com a prova de identidade durante a reserva, validar as atestações e posteriormente verificar o cliente presencialmente na entrega antes de libertar o veículo. Os utilizadores podem partilhar as suas mDLs com empresas de aluguer de automóveis, quer presencialmente quer remotamente, com antecedência.

Um balcão de aluguer não precisa principalmente de investigar um incidente. Precisa de decidir: Posso alugar este veículo a este cliente ao abrigo desta reserva e desta apólice?

A pré-verificação remota deve incluir:

• Ligação de identidade
• Fotografia ou elemento equivalente de vinculação de identidade
• Categoria de veículo relevante
• Datas de emissão e de validade
• Validade atual
• Possivelmente um limiar de idade ou uma faixa etária

A entrega deve confirmar:

• O titular é a mesma pessoa que concluiu a pré-verificação
• Validade atual
• Habilitações relevantes

Não necessário por defeito:

• Morada completa quando um perfil de reserva já contém dados de contacto
• Data de nascimento completa quando uma confirmação de idade ou faixa etária é suficiente
• Atributos de identidade não relacionados
• Reapresentação repetida da credencial completa, caso já exista uma atestação de reserva

A arquitetura mDL atual da NIST mostra a parte requerente a utilizar DCQL para solicitar apenas os atributos necessários, e afirma explicitamente que isto suporta a minimização de dados e o consentimento do titular ao estruturar o pedido em vez de tratar a credencial como uma unidade única. A AAMVA acrescenta que a aplicação deve mostrar claramente que dados foram solicitados e se o verificador tenciona reter a informação.

3. Empregadores: Uma Categoria de Verificador, Não Uma Janela para a Identidade Completa

A visão geral do W3C utiliza o sistema digital de um empregador a verificar um grau universitário como exemplo de verificador. Isso recorda-nos que a verificação por entidades empregadoras já é um padrão reconhecido nos ecossistemas de credenciais.

Um empregador ou operador de frota pode legitimamente necessitar de saber:

• Se um trabalhador está atualmente habilitado a conduzir determinadas categorias de veículos
• Se existem restrições relevantes
• Se a habilitação permanece válida

Esta é uma necessidade empresarial real. Mas não justifica automaticamente o acesso permanente à totalidade da credencial de condução, aos dados de identidade completos ou a um fluxo contínuo de apresentações repetidas.

A NIST adverte que a transmissão frequente de um identificador reutilizável e o condicionamento dos utilizadores a apresentarem repetidamente uma credencial de identidade são indesejáveis, e refere que a autenticação do dia a dia deve basear-se em tecnologias concebidas para autenticação, como as passkeys. A NIST prefere a autenticação local no dispositivo à correspondência biométrica no servidor, por preservar melhor a privacidade.

Um futuro PIC não deve tornar-se um crachá de acesso ao local de trabalho.

Para uso por empregadores e frotas, o padrão correto é habitualmente:

• Uma verificação de habilitação relevante para o cargo
• Talvez uma atestação periódica de conformidade
• Talvez uma declaração de que o titular continua válido para categorias especificadas
• Mas não uma transferência automática de todos os dados da carta cada vez que o trabalhador inicia sessão num sistema ou começa um turno

A conformidade de frotas é uma categoria de parte requerente distinta, com uma finalidade pretendida distinta e um perfil de divulgação distinto.

4. Seguradoras: As Participações de Sinistro Não São Permissão para Visibilidade Contínua

O caso das seguradoras é frequentemente real. No material de casos de utilização da mDL da UE, as seguradoras surgem indiretamente no cenário de aluguer: as seguradoras exigem às empresas de aluguer de automóveis que verifiquem se a pessoa que aluga o carro tem o direito de conduzir. O setor segurador já influencia o fluxo de verificação da condução.

Mas isso não significa que uma seguradora deva receber os mesmos dados que a polícia, ou um direito permanente de acesso à credencial.

Um futuro PIC deve tratar as seguradoras como uma categoria de verificador distinta, com finalidades pretendidas distintas:

• Subscrição
• Verificação de risco de aluguer
• Tratamento de participações de sinistro
• Análise de fraude

Estas não são a mesma finalidade. Ao abrigo dos princípios europeus de proteção de dados, os dados pessoais devem ser recolhidos para finalidades especificadas e limitados ao que é necessário e proporcional para essa finalidade. As orientações VC do W3C chegam à mesma conclusão do ponto de vista técnico: os verificadores devem solicitar apenas o estritamente necessário.

Exemplos legítimos e específicos a um evento:

• Prova de que a carta era válida no momento relevante
• Prova da habilitação relevante para o veículo
• Prova de ligação de identidade quando necessário para uma participação de sinistro
• Divulgação específica à participação de sinistro

Não permitido por defeito:

• Acesso persistente à credencial subjacente
• Verificação genérica repetida sempre que o cliente interage com a seguradora
• Utilização da credencial de condução como token de autenticação
• Recolha de atributos não relacionados

Uma credencial de condução não é uma subscrição de monitorização. E não deve tornar-se silenciosamente numa.

Por Que os Intermediários Devem Ser Visíveis

Os mercados reais envolvem intermediários. Plataformas de aluguer, fornecedores de gestão de frotas, sistemas de recursos humanos de empregadores e processadores de participações de sinistro de seguradoras atuam frequentemente através de terceiros.

A arquitetura EUDI trata desta questão:

• Tratando os intermediários como partes requerentes
• Exigindo o seu registo
• Exigindo que os atributos solicitados para a parte requerente intermediada sejam registados
• Mostrando ao utilizador tanto o intermediário como a parte requerente final
• Proibindo os intermediários de armazenar dados sobre o conteúdo da transação

Um futuro PIC nunca deve permitir um padrão em que o utilizador acredita estar a divulgar dados à empresa de aluguer, quando na realidade está a divulgá-los a uma cadeia invisível de mediadores de verificação, processadores de análise e fornecedores de sinistros.

O ETSI é útil aqui. O seu modelo de certificado para partes requerentes de carteiras digitais inclui URIs de suporte, finalidade pretendida, URIs de registo e metadados de autoridade de supervisão. Este é o tipo de infraestrutura legível por máquina necessária para que os utilizadores compreendam quem está realmente do outro lado do pedido e onde devem recorrer quando pretendem a eliminação ou correção de dados.

A Retenção Faz Parte do Controlo de Acesso

A maioria das discussões sobre divulgação seletiva termina demasiado cedo. Centram-se no que é divulgado. Não se centram suficientemente no tempo que os dados permanecem disponíveis depois disso.

As orientações atuais já estão a convergir:

• AAMVA: a carteira digital deve informar claramente o titular sobre que dados foram solicitados e se o verificador tenciona retê-los; as partes interessadas não devem rastrear titulares nem a utilização da mDL, exceto quando exigido por lei
• W3C: o software do titular deve fornecer registos das informações partilhadas com os verificadores, para que pedidos excessivos possam ser identificados
• EUDI: os utilizadores devem poder aceder aos registos de transações, reportar pedidos suspeitos e solicitar o apagamento de dados

A classe de retenção deve fazer parte da própria política de divulgação:

• Fiscalização policial na berma da estrada: sem retenção por defeito para além do registo operacional legalmente previsto
• Pré-verificação de aluguer: registo de transação associado à reserva, não uma cópia de identidade reutilizável
• Conformidade de frota do empregador: registo de conformidade ou resultado de atestação, não dados brutos da credencial
• Participação de sinistro de seguradora: registo de sinistro limitado à participação, sem acesso permanente

Um futuro PIC que ignore a retenção é apenas parcialmente preservador da privacidade.

O Que a Carteira Digital Deve Realmente Decidir

Se tivesse de reduzir todo este artigo a uma única regra de implementação, seria esta:

A carteira digital não deve responder a “Posso apresentar esta credencial?” Deve responder a “Posso apresentar este conjunto de declarações a este verificador autenticado, para esta finalidade pretendida, neste contexto e sob esta classe de retenção?”

Essa decisão deve ser guiada, pelo menos, pelos seguintes elementos:

• Identidade do verificador
• Categoria do verificador
• Finalidade pretendida
• Âmbito de atributos registado
• Política de divulgação do emissor, se presente
• Ambiente (berma da estrada, entrega, remoto, frota, participação de sinistro)
• Aprovação do titular
• Política de retenção aplicável

As normas já contêm grande parte dos mecanismos necessários: divulgação seletiva, autenticação da parte requerente, finalidade pretendida registada, certificados de acesso, avaliação de políticas de divulgação e pedidos vinculados a uma finalidade. O que ainda falta é a disciplina para tratar esses elementos como uma arquitetura de divulgação coerente.

O Argumento Central

O futuro PIC não deve questionar se os dados podem ser divulgados. Deve questionar:

• Quem está a solicitar?
• Para que finalidade?
• Ao abrigo de que autoridade?
• Em que contexto?
• Com que consequências em termos de retenção?

A polícia, os balcões de aluguer, os empregadores e as seguradoras não são quatro logótipos do outro lado de um pedido. São quatro modelos de risco diferentes, quatro contextos jurídicos diferentes, quatro razões diferentes para solicitar — e devem produzir quatro conjuntos de divulgação diferentes.

Isso não é complexidade desnecessária. É o que uma credencial de condução moderna parece quando deixa de tratar todos os verificadores como o mesmo verificador.