Por Que a Blockchain É Opcional para a Futura Licença Internacional de Condução (IDP)

Uma futura Licença Internacional de Condução (IDP) necessita de transparência, âncoras de confiança e responsabilidade pública. O que não necessita — por defeito — é de colocar os próprios condutores num livro-razão distribuído.

Qualquer conversa séria sobre um IDP digital e transfronteiriço acaba por atrair a mesma proposta: “Basta colocá-lo na blockchain.” O apelo é compreensível. As blockchains oferecem evidências de adulteração, visibilidade partilhada e um histórico append-only. Estas são propriedades reais. Mas, no contexto da identidade transfronteiriça de condutores, são frequentemente aplicadas à camada errada.

Este artigo explica porquê, analisa o que as normas realmente dizem e apresenta um padrão arquitetónico melhor.

O Que as Normas Realmente Dizem Sobre a Blockchain

O Modelo de Dados de Credenciais Verificáveis da W3C é explícito ao afirmar que um registo de dados verificáveis pode assumir muitas formas, incluindo:

• Bases de dados confiáveis
• Bases de dados descentralizadas
• Bases de dados de identidade governamentais
• Livros-razão distribuídos

O DID Core é igualmente claro: muitos métodos DID utilizam tecnologia de livro-razão distribuído, mas nem todos o fazem. Por outras palavras, as normas já rejeitam a ideia de que a blockchain é uma base obrigatória para credenciais digitais.

Este é o ponto de partida correto para um futuro IDP. A questão útil não é “blockchain ou sem blockchain?” É:

Qual camada realmente necessita de transparência, e qual camada absolutamente não deve tornar-se infraestrutura pública por defeito?

A Blockchain É um Conjunto de Propriedades, Não um Requisito

O primeiro erro é tratar a “blockchain” como um único requisito. Não o é. É um conjunto de propriedades possíveis, incluindo:

• Publicação partilhada
• Histórico append-only
• Operação distribuída
• Geração de recibos
• Resistência a alterações unilaterais

Algumas destas propriedades são úteis para um futuro IDP. Algumas são irrelevantes. E algumas são ativamente perigosas quando aplicadas a sujeitos humanos de credenciais. O modelo de registo da W3C permite deliberadamente múltiplas implementações porque diferentes ecossistemas necessitam de diferentes compromissos.

Três Problemas Que Não Devem Ser Combinados

O segundo erro é colapsar três problemas diferentes num único sistema. Para um futuro IDP, estes precisam de permanecer separados:

1. Onde reside a verdade jurídica. O direito de conduzir pertence aos registos nacionais autorizados de licenças.
2. Como o material de confiança é distribuído. As chaves do emissor e os certificados do verificador pertencem a registos de confiança controlados.
3. Como o ecossistema audita as alterações. Isto pertence a uma camada de transparência.

Os ecossistemas do mundo real já funcionam desta forma. O Serviço de Confiança Digital da AAMVA distribui chaves públicas do emissor numa lista descarregável antes de um verificador interagir com um mDL. O manual de licença de condução móvel da UE especifica que os Estados-Membros notificam a Comissão dos emissores de mDL autorizados, e a Comissão publica uma lista de verificação dessas autoridades. Isso é distribuição de confiança sem blockchain.

O Que a Transparência de Certificados Nos Ensina

O modelo de transparência mais eficaz na internet pública não é uma blockchain de consumo. É a Transparência de Certificados (CT).

O RFC 9162 descreve a CT como um protocolo para registar publicamente certificados de servidor TLS de modo a que qualquer pessoa possa:

• Auditar a atividade das autoridades de certificação
• Detetar certificados problemáticos ou emitidos incorretamente
• Auditar os próprios registos

A principal lição de design da CT: a transparência é mais valiosa quando regista o comportamento do emissor e o material de confiança — não a atividade do utilizador final.

Aplicado a um futuro IDP, isso significa registar coisas como:

• Emissão e rotação de chaves do emissor
• Publicação de âncoras de confiança
• Registo de categorias de verificadores
• Alterações de política
• Declarações de conformidade
• Eventos relevantes para a segurança

O que não significa é criar um livro-razão público ou semipúblico de titulares, identificadores de credenciais ou eventos de apresentação. Isso não é transparência. É recolha excessiva de dados.

SCITT: Por Que a Transparência Não É o Mesmo Que a Verdade

O rascunho de arquitetura SCITT do IETF expande este pensamento. O SCITT define um Serviço de Transparência que mantém uma estrutura de dados verificável e emite recibos criptográficos que provam a inclusão de declarações assinadas. A identidade do Serviço de Transparência é capturada por uma chave pública conhecida das partes confiantes, e as âncoras de confiança e as políticas de registo são elas próprias tornadas transparentes.

Este é um modelo poderoso para a infraestrutura IDP porque transforma a transparência num serviço auditável em torno do material de confiança e da política — não em torno de eventos de viagem pessoais.

O SCITT é também claro quanto aos limites da transparência:

• Uma declaração registada apenas prova que um emissor a produziu e registou — não que a declaração é correta indefinidamente.
• Uma declaração assinada posterior pode substituir uma anterior.
• A transparência não impede emissores desonestos ou comprometidos; responsabiliza-os.

Para a identidade do condutor, essa distinção é enormemente importante: um registo de transparência é evidência e histórico de auditoria, não o estado jurídico autoritativo do direito de condução de alguém.

O SCITT também observa que um serviço de transparência pode proteger a sua sequência append-only usando uma combinação de hardware confiável, protocolos de consenso e evidências criptográficas. Mesmo a camada de transparência não requer um design de blockchain específico. O consenso é uma opção, não a única opção.

A Separação Arquitetónica Correta para um Futuro IDP

Um futuro IDP deve separar as preocupações em quatro camadas distintas:

1. Registos autoritativos de quem pode conduzir (autoridades nacionais de licenciamento)
2. Registos de confiança para chaves de emissor e verificador
3. Infraestrutura de estado para atualização e revogação
4. Uma camada de transparência opcional para auditoria pública de políticas, âncoras de confiança, recibos e declarações de conformidade

Ao separar estas camadas, a questão da blockchain torna-se muito mais precisa. Já não é “deve o futuro IDP estar numa blockchain?” Torna-se:

Qual camada, se alguma, beneficia realmente de auditoria pública append-only?

Cinco Razões Pelas Quais a Identidade do Condutor On-Chain É o Padrão Errado

1. Cria Sinais de Rastreamento Duráveis

O trabalho de privacidade da EUDI explica que as apresentações de atestação podem conter valores únicos tais como:

• Salts
• Valores de hash
• Identificadores de revogação
• Chaves públicas de vinculação de dispositivo
• Assinaturas
• Marcas de tempo

Como esses valores são fixos para a mesma atestação, permitem que as partes confiantes liguem diferentes transações e construam um perfil comportamental do utilizador. A EUDI adverte explicitamente que isto viola a expectativa razoável de que atividades separadas da carteira não serão combinadas.

Se publicar identificadores estáveis de titulares, identificadores estáveis de credenciais, hashes reutilizáveis ou eventos de revogação individualmente rastreáveis num livro-razão público, não está a resolver o problema de rastreamento — está a torná-lo permanente.

2. Expõe Eventos de Revogação e Atualização

A Recomendação de Lista de Estado Bitstring da W3C descreve o problema claramente: se houver um mapeamento um-para-um entre uma credencial e o URL onde o seu estado é publicado, o publicador pode conectar o titular, o verificador e o momento da verificação. A especificação usa um exemplo de carta de condução para ilustrar por que ser rastreado pelo emissor ao entrar num estabelecimento viola uma expectativa de privacidade comum.

O padrão melhor que a Lista de Estado Bitstring propõe:

• Listas de estado grandes e comprensíveis onde muitas credenciais partilham um recurso de estado
• Um comprimento de lista predefinido de 131 072 entradas
• Partes confiantes a descarregar novas versões separadamente, sem se autenticarem
• Índices aleatorizados e garantias de privacidade de grupo

Isso é o oposto de rastreamentos de revogação individualizados e on-chain.

3. Confunde o Estado da Credencial com o Estado Jurídico de Condução

Uma credencial digital pode ser revogada porque o seu mecanismo de assinatura foi comprometido — mesmo enquanto o direito de condução no mundo real permanece válido. Um livro-razão público de eventos de credenciais não é um substituto claro para o estado autoritativo de um registo nacional de condução.

O SCITT reforça o ponto: uma declaração registada pode ser posteriormente substituída por uma nova, e as partes confiantes decidem em que confiar com base na política e no histórico. O registo não é a verdade permanente. É evidência sobre quem disse o quê, quando, sob qual política. A autoridade nacional de licenciamento permanece a raiz da verdade jurídica.

4. Aborda o Problema de Governação Errado

A identidade transfronteiriça do condutor não é principalmente um problema de consenso. É um problema de governação:

• Quem tem permissão para emitir?
• Quais chaves públicas são atuais?
• Quais verificadores estão autorizados?
• Quais pedidos de dados correspondem ao seu propósito declarado?
• Qual versão de política estava em vigor na altura?

Os ecossistemas reais já respondem a estas questões através de infraestrutura de confiança governada, não de consenso descentralizado:

• O Serviço de Confiança Digital da AAMVA publica as chaves públicas das autoridades emissoras numa lista descarregável.
• O manual de licença de condução móvel da UE afirma que a Comissão publica a lista de emissores de mDL autorizados.
• O trabalho de certificação de parte confiante da carteira da ETSI fornece autenticação de verificadores legível por máquina com uso pretendido e atributos solicitados registados.

Isso é administração pública explícita de confiança — não governação descentralizada.

5. Não Resolve a Realidade à Beira da Estrada

Muitas propostas de blockchain assumem silenciosamente que o acesso em tempo real à rede é um benefício. Para credenciais de condutores — particularmente à beira da estrada ou durante viagens — frequentemente não o é.

As orientações de implementação da AAMVA especificam que:

• A recuperação do dispositivo funciona sem conetividade externa tanto para o titular como para o leitor no momento da transação.
• A ISO/IEC 18013-5 requer suporte para recuperação do dispositivo.
• O acesso do verificador às chaves públicas do emissor não precisa de acontecer no momento da transação. As chaves podem ser descarregadas antecipadamente.

Se um verificador já pode validar localmente usando material de confiança em cache, uma dependência de blockchain em tempo real não é essencial. Na melhor das hipóteses, é uma escolha de implementação para alguma função de auditoria de backend.

O Que Deve Ser Transparente num Futuro IDP

Um futuro IDP definitivamente necessita de transparência — no lugar certo.

Tornar estes transparentes por defeito:

• Chaves públicas do emissor e eventos de rotação de chaves
• Âncoras de confiança e listas de emissores autorizados
• Certificados de acesso de verificadores e metadados de propósito registado
• Versões de política e regras de registo
• Declarações de conformidade e reivindicações de versão de software relevantes para a segurança
• Recibos auditáveis que provam que estas declarações foram registadas

Não tornar estes públicos por defeito:

• Identificadores de titulares num livro-razão público
• Identificadores estáveis de credenciais reutilizados entre verificadores
• Eventos por apresentação
• Entradas brutas de revogação que isolam uma pessoa
• Declarações assinadas completas contendo dados pessoais quando hashes ou metadados seriam suficientes

O SCITT adverte explicitamente os emissores a rever a inclusão de informações privadas, confidenciais ou pessoalmente identificáveis antes de submeter declarações a um serviço de transparência. Também observa que os serviços de transparência podem reter apenas metadados criptográficos, como hashes — não declarações assinadas completas.

Um Padrão Melhor: Transparência em Torno do Ecossistema, Não Através da Pessoa

Uma arquitetura limpa para um futuro IDP tem este aspeto:

• Registo nacional autoritativo — permanece a fonte jurídica de verdade para o direito de condução.
• Camada de credenciais — transporta direitos de condução verificáveis por máquina para a carteira do titular.
• Camada de registo de confiança — distribui chaves do emissor, certificados do verificador e listas de emissores autorizados.
• Camada de estado — utiliza atestações de curta duração ou listas de estado que preservam a privacidade, atualizadas separadamente.
• Camada de transparência — pode ou não utilizar consenso internamente, e regista âncoras de confiança, alterações de chaves, atualizações de políticas, recibos e declarações do ecossistema que beneficiam de auditoria pública append-only.

Esta arquitetura captura as partes úteis do pensamento blockchain — auditabilidade append-only, escrutínio público, evidências de adulteração, recibos — sem tornar o condutor no sujeito público do sistema. Também corresponde ao que as normas já descrevem: os registos podem assumir diferentes formas, os DIDs não requerem livros-razão distribuídos, os registos de confiança já existem e os mecanismos de estado que preservam a privacidade já estão normalizados.

O Argumento Central

O futuro IDP deve adotar a melhor ideia da blockchain — responsabilidade pública para a infraestrutura — sem adotar o seu pior padrão para as pessoas: rastreamento durável e globalmente visível.

Na prática, isso significa:

• Transparência para emissores, não exposição de titulares
• Âncoras de confiança auditáveis, não registos públicos de viagem
• Recibos para políticas e registos, não cronologias permanentes de uso de credenciais
• Evidências append-only para a governação do ecossistema, não identidade do condutor on-chain como padrão

Este não é um argumento contra a blockchain. É um argumento contra a aplicação da blockchain à camada errada.

Um futuro IDP pode muito bem utilizar serviços de transparência apoiados por consenso em algum lugar do ecossistema. Mas se o design começar por colocar o condutor, a credencial ou o rastro de apresentação num livro-razão, já escolheu o padrão errado.