What is a mobile driver license (mDL)?

An mDL is the digital equivalent of a plastic driver's license, issued by your state DMV (or national authority) and stored in a wallet app on your phone. It is governed by ISO/IEC 18013-5, an international standard that specifies how attributes are signed, transferred, and verified. US states including Arizona, Colorado, Maryland, Georgia, Iowa, Mississippi, Ohio, Utah, Virginia, and a growing list are issuing mDLs; California has it in production; the EU is rolling out its own variant under EUDI Wallet (eIDAS 2.0).

What's encoded in the QR?

Under ISO/IEC 18013-5 section 8.2, the QR carries a CBOR-encoded DeviceEngagement structure. That structure declares the wallet's ephemeral public key (eDeviceKey), the cipher suite used (currently P-256 / ECDH-ES), and the list of transfer methods the wallet supports (NFC, Bluetooth LE, Wi-Fi Aware). It does NOT carry the actual license attributes (name, DOB, license number, photo). Those are sent over the chosen transfer channel AFTER the verifier requests specific attributes and the holder approves.

How is this different from the PDF417 barcode on the back of a plastic license?

Completely different. The PDF417 barcode on plastic AAMVA cards encodes every attribute on the card in plaintext, name, address, DOB, license number, restrictions, donor status, and any scanner can read all of it. An mDL QR is just a handshake. The verifier has to ASK for specific attributes (e.g. 'over 21? yes/no') and the holder has to APPROVE the release on their phone. The wallet can answer 'over 21 = yes' without disclosing the actual date of birth, that's called selective disclosure.

What does selective disclosure mean in practice?

A bartender scanning your mDL needs to know one thing: are you of legal drinking age? With a plastic license, you hand over the card and they see your full address, DOB, and license number. With an mDL the bartender's verifier app requests only the age_over_21 attribute. Your phone shows you that request, you approve, and a signed boolean is transferred. Nothing else. ISO/IEC 18013-5 supports a long list of such derived attributes (age_over_18, age_over_21, age_over_65), plus full attributes when actually needed (a car rental probably needs full name and license number; a bouncer doesn't).

What's a hostile verifier and how do I spot one?

A hostile verifier is a verifier app that asks for more attributes than the transaction needs, e.g. a bar asking for full address, license number, and photo when it only needs age_over_21. This is a real risk because verifier apps are not centrally regulated; anyone can build one. The mDL standard requires the wallet to display the full list of requested attributes before the holder approves, so the defense is reading that list. If the bar wants your home address to pour a beer, decline. ISO/IEC 18013-5 also supports verifier authentication (the verifier signs its request with a certificate from a trust list), so a scrupulous wallet warns when the verifier isn't on a known trust list. The list of recognized verifiers is jurisdiction-specific and still maturing.

Padrões · Carteira de motorista digital (mDL)

QR codes de carteira de motorista digital: ISO/IEC 18013-5

Quando um bartender, agente da TSA ou atendente de locadora escaneia o QR no app de carteira de motorista do seu celular, esse QR não é a carteira. É um handshake. Os atributos reais só trafegam depois que o verificador deles solicita campos específicos e você aprova a liberação no celular. Feito certo, um mDL expõe muito menos do que um cartão físico. Feito errado (verificador hostil, aprovação em branco), expõe o mesmo ou mais. Veja como distinguir.

Inspecionar um QR de mDL → Todos os padrões →

Qual é o padrão

ISO/IEC 18013-5:2021, Identificação pessoal, carteira de motorista conforme ISO, Parte 5: Aplicação de carteira de motorista digital (mDL). O padrão internacional que especifica como carteiras de motorista digitais são emitidas, armazenadas, transferidas para um verificador e verificadas offline. A superfície de QR code (a parte que a maioria das pessoas vê) é a seção 8.2 "Recuperação pelo dispositivo, engajamento via QR code". Um padrão complementar, ISO/IEC 18013-7, cobre a recuperação online (o verificador consulta o emissor diretamente com o consentimento do titular).

A adoção está bem avançada: uma dúzia de estados americanos têm mDLs em produção ou piloto na Apple Wallet e Google Wallet; o mDL da Califórnia está em disponibilidade geral; a TSA aceita mDLs na segurança na maioria dos grandes aeroportos dos EUA; a UE está integrando sua variante à EUDI Wallet sob o eIDAS 2.0 (regulamento em vigor no final de 2024, carteiras previstas para 2026-2027). O padrão é também a base da ISO/IEC 23220 (estrutura geral de credenciais digitais, cobrindo itens além de carteiras de motorista).

O que está realmente dentro do QR

O QR de mDL codifica uma estrutura CBOR de DeviceEngagement. CBOR (Representação Concisa de Objetos Binários, RFC 8949) é uma alternativa binária compacta ao JSON. A estrutura decodificada tem aspecto aproximado de:

{
  0: "1.0",                         // version
  1: [1, 2, [eDeviceKey bytes]],    // security: cipher suite 1, EC P-256 key
  2: [                              // device retrieval methods
    [1, 1, {...NFC options...}],
    [2, 1, {...BLE options...}],
    [3, 1, {...Wi-Fi Aware options...}]
  ],
  3: {...optional server retrieval...}
}

Campos principais, decodificados:

Versão

Sempre "1.0" nos deployments atuais. Revisões futuras podem incrementar.

Conjunto de cifras

Atualmente sempre 1: acordo de chaves ECDH em P-256, criptografia de sessão AES-GCM. O conjunto de cifras 2 está reservado para brainpoolP320r1 (casos de uso na UE).

eDeviceKey

Uma chave pública EC efêmera gerada por sessão pela carteira. Usada pelo verificador para configurar uma sessão criptografada. Descartada após a transação. Nosso scanner mostra o comprimento deste campo, mas nunca exibe os bytes da chave — eles são efêmeros e só fazem sentido para a sessão do verificador em andamento.

Métodos de transferência

A carteira informa ao verificador quais canais está disposta a usar para a transferência real dos atributos: NFC (aproximação), Bluetooth LE ou Wi-Fi Aware (Wi-Fi ponto a ponto sem ponto de acesso). A maioria dos mDLs oferece BLE e NFC; o Wi-Fi Aware tem suporte limitado por plataforma.

Recuperação pelo servidor (opcional)

Quando presente, a carteira suporta o modo 18013-7: o verificador pode solicitar atributos da API online do emissor em vez de diretamente da carteira. O QR inclui a URL do emissor. Nosso scanner extrai isso e mostra qual autoridade receberia a consulta.

Como é diferente do PDF417 AAMVA no cartão físico?

É uma categoria diferente de credencial. O código de barras PDF417 AAMVA no verso de uma carteira de motorista física dos EUA contém todos os atributos do cartão em texto simples — nome, endereço, data de nascimento, número da habilitação, altura, peso, cor dos olhos, restrições, indicação de doação de órgãos. Qualquer scanner consegue ler tudo. O cartão é uma credencial de "tudo ou nada": você o entrega e divulga tudo, ou não entrega.

Um mDL inverte isso. O QR não contém atributos — apenas um handshake. O verificador precisa solicitar atributos específicos (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges, etc.), a carteira mostra a solicitação para você e somente os atributos que você aprovar são transferidos. A transferência também é assinada criptograficamente pela autoridade emissora (seu Detran), para que o verificador confirme a autenticidade dos atributos sem precisar se conectar a um servidor — a verificação offline funciona.

É por isso que pessoas preocupadas com privacidade preferem mDLs mesmo sendo o padrão mais complexo: ele permite divulgação adequada à transação. Um porteiro não precisa do seu endereço; um agente da TSA não precisa da sua indicação de doação de órgãos; um caixa de conveniência não precisa do número da sua habilitação.

Divulgação seletiva: o objetivo real

O padrão mDL define um conjunto de atributos derivados que permitem ao verificador fazer uma pergunta sim/não em vez de receber um valor bruto. Os principais:

age_over_18, age_over_21, age_over_65, para compras com restrição de idade sem divulgar a data de nascimento.
resident_state, para perguntas sobre residência no estado sem divulgar o endereço.
driving_privileges, categoria da habilitação e restrições; para locação de veículos.

Um app verificador bem projetado para um bar pede apenas age_over_21. A carteira mostra "Bar XYZ quer saber se você tem mais de 21 anos." Você toca em Aprovar, um único booleano assinado ("verdadeiro") é enviado de volta. O app do bar verifica a assinatura contra a raiz de confiança mDL publicada pelo seu estado. Pronto. Sem data de nascimento, sem nome, sem número da habilitação, sem foto. Comparado a entregar o cartão físico, isso é uma grande melhoria de privacidade.

Verificadores hostis: o novo modelo de ameaça

O modelo de ameaça do cartão físico era simples: perdê-lo, copiá-lo, ter os dados vistos por cima do ombro. O modelo de ameaça do mDL é diferente. O formato é sólido; a criptografia é robusta; o risco migra para o app verificador do outro lado da transação.

Qualquer pessoa pode criar um app verificador. Não há autoridade central de licenciamento. Assim, um bar pode usar um verificador pronto configurado para pedir data de nascimento completa, nome completo e foto, mesmo precisando apenas de age_over_21. Um atendente de locadora pode pedir tudo "para o arquivo". Um caixa de loja pode pedir o endereço. Nada disso é tecnicamente proibido pelo padrão — ele apenas exige que a carteira mostre ao titular o que está sendo solicitado e requeira aprovação explícita.

Portanto, a defesa está do lado do titular: leia o prompt de solicitação. Se o verificador pedir mais do que a transação precisa, recuse. Algumas carteiras alertam quando o verificador não está em uma lista de confiança conhecida; a ISO/IEC 18013-5 suporta autenticação de verificadores via certificados, mas a infraestrutura de listas de confiança ainda está em maturação (listas por estado nos EUA; lista de confiança da UE sob o eIDAS 2.0).

Vale saber também: o verificador vê sua eDeviceKey, o conjunto de cifras e quais métodos de transferência você suporta — só isso. Ele não obtém atributos somente com o QR. Então escanear um QR de um adesivo ou da tela de alguém e ir embora não dá ao atacante nada útil. Os atributos só trafegam dentro da sessão criptografada após o handshake.

O que nosso scanner mostra

Envie um QR DeviceEngagement de mDL (imagem, colagem ou câmera) para o nosso scanner. O resultado mostra:

Padrão, ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
Versão, geralmente 1.0.
Conjunto de cifras, o conjunto de cifras nomeado (P-256 / brainpool / etc.).
Métodos de transferência, quais canais a carteira oferece (NFC, BLE, Wi-Fi Aware).
Host de recuperação pelo servidor, se a carteira oferece o modo 18013-7, qual URL do emissor trataria as solicitações de atributos.
Comprimento da eDeviceKey, confirma que a chave está presente e bem formada, sem exibir os bytes.

NÃO decodificamos nenhum atributo — não há atributos no QR, por design. Os dados reais da carteira trafegam criptografados pelo método de transferência escolhido para um verificador real.

A decodificação ocorre no seu navegador; apenas os metadados estruturais chegam ao nosso servidor para a classificação de segurança.

Antes de aprovar uma solicitação do verificador

Leia o prompt de solicitação. Sua carteira é obrigada pelo padrão a mostrar a lista completa de atributos solicitados. Leia.
A solicitação corresponde à transação? Bartender pedindo data de nascimento completa em vez de age_over_21 = recuse ou pergunte o motivo. Atendente de locadora pedindo informação de doação de órgãos = recuse.
O verificador está em uma lista de confiança? Algumas carteiras exibem um selo para verificadores conhecidos (com certificados do órgão emissor do seu estado). Verificadores desconhecidos merecem cautela.
A recuperação online (18013-7) é mais poderosa e mais invasiva. Se a carteira perguntar se você permite que o verificador consulte diretamente o Detran, isso cria um registro de auditoria no órgão. Adequado para algumas transações (controle de fronteira, verificações oficiais de identidade), desnecessário para outras (comprar bebida).
Você sempre pode recusar. O objetivo da divulgação seletiva é que você controle o que sai do seu celular. Se um verificador não aceitar uma divulgação reduzida, você pode voltar ao documento físico ou abandonar a transação.

Relacionados

AAMVA driver license PDF417, o código de barras do cartão físico que este formato substitui.
QR de passkey FIDO2, outro QR de handshake entre dispositivos.
Golpes com QR code a observar em 2026
Todos os padrões QR que verificamos
Lista completa de cobertura

Inspecionar um QR DeviceEngagement de mDL

Envie o QR (imagem, colagem ou câmera). O resultado mostra versão, conjunto de cifras, métodos de transferência e qualquer URL de recuperação pelo servidor opcional. Sem atributos — eles só trafegam dentro da sessão criptografada pós-handshake para um verificador real.

Abrir scanner →