Não escolhe um. O quadro EUDI exige suporte a ambos, e o Quadro de Arquitectura e Referência já os atribui: a apresentação por proximidade segue a ISO/IEC 18013-5, e a apresentação remota passa por OpenID for Verifiable Presentations, onde ambos os formatos estão perfilados.
Portanto a decisão real é a sequência. Se os seus utilizadores apresentam remotamente, num browser ou numa aplicação, construa SD-JWT VC primeiro. Se apresentam presencialmente, num balcão ou numa cancela, construa ISO mdoc primeiro.
O facto datado que resolve a maior parte do argumento é um regulamento de execução da Comissão. O OpenID4VC High Assurance Interoperability Profile, versão 1.0, é referenciado no CIR (UE) 2026/1731, e esse perfil cobre OpenID for Verifiable Credential Issuance, OpenID for Verifiable Presentations, IETF SD-JWT VC e ISO mdoc em conjunto, num único documento. É essa a resposta à pergunta sobre qual é o formato europeu. Ambos.
Quais são as diferenças concretas na implementação?
O ARF deixa-lhe realmente escolher?
Não no modo de apresentação, que é a parte que a maioria pensa ser uma escolha. O Quadro de Arquitectura e Referência é explícito. Para fluxos de apresentação remota, a carteira implementa OpenID for Verifiable Presentations. Para fluxos de apresentação por proximidade, adere à ISO/IEC 18013-5. Essa decisão já está tomada, e mapeia quase exactamente nos dois formatos, porque a ISO 18013-5 é ao mesmo tempo um formato e um protocolo de proximidade.
Onde tem margem é nos fluxos remotos. Em OpenID4VP, tanto mso_mdoc como dc+sd-jwt são válidos, e o perfil de alta garantia cobre emissão combinada de ambos. Portanto um serviço só remoto pode razoavelmente começar apenas com SD-JWT VC e acrescentar mdoc depois. Se a obrigação lhe chega ou não é uma questão separada, coberta em which sectors must accept the EUDI Wallet. O trabalho de engenharia em volta está no nosso guia de integração de relying party.
O que significa o estado de draft do SD-JWT VC para um projecto que começa agora?
Significa que fixar a versão é uma tarefa a sério, não uma formalidade. O SD-JWT é RFC 9901 e estável. O SD-JWT VC é draft-ietf-oauth-sd-jwt-vc-18, datado de 3 de agosto de 2026, em via de normalização e ainda não um RFC. A Comissão Europeia avaliou o draft 11 de outubro de 2025 e não identificou lacunas, notando que a especificação continuava a evoluir e precisaria de reavaliação quando final.
O ecossistema respondeu exactamente a este problema. Em outubro de 2025 tanto o OpenID4VCI como o OpenID4VP fixaram a versão de SD-JWT VC que referenciam, e o perfil de alta garantia seguiu. Portanto a resposta prática não é seguir o último draft. É seguir o draft que o perfil ao qual está a conformar-se fixou, e registar esse número de versão na sua própria documentação.
O que tem realmente de construir do lado do verificador?
Os formatos diferem, e o trabalho em volta é em larga medida o mesmo, o que significa que a decisão de formato é menor do que parece. Comum aos dois: construir o pedido de apresentação, onde o trabalho recente de OpenID4VP usa DCQL em vez das abordagens anteriores de presentation definition. Resolver a confiança, que no contexto europeu significa resolução de listas de confiança ETSI e a Lista de Listas de Confiança, um modelo diferente da certificate chain validation used with the Portuguese Citizen Card. Verificar a ligação ao portador quando é imposta. Verificar o estado. E decidir o que guardar, que é um registo de que uma verificação ocorreu e não uma cópia da credencial.
Então qual constrói primeiro?
Quatro perguntas, por esta ordem. A primeira que der uma resposta clara decide. Os utilizadores apresentam alguma vez presencialmente, num balcão, cancela ou dispositivo, e nesse caso ISO mdoc primeiro, porque a proximidade é 18013-5 e não há caminho alternativo. Toda a interacção é remota, e nesse caso SD-JWT VC primeiro, pelo menor custo de integração. Já sabe em que formato emite a sua primeira contraparte real, e nesse caso iguale-a, porque testar contra algo real vale mais do que preferência arquitectural. E está a construir para um sector onde o mDL é a credencial primária, como transportes ou aluguer de veículos, e nesse caso mdoc primeiro, e conte que continue primário.
E uma instrução arquitectural que sobrevive a qualquer das respostas. Mantenha o tratamento de formato atrás de uma interface, e faça a lógica da aplicação perguntar o que foi verificado e a que nível de garantia, nunca o que a credencial contém estruturalmente. O segundo formato vem a caminho. Chegue em seis meses ou em dois anos, o custo de o acrescentar é fixado por uma decisão que toma agora.
Perguntas frequentes
Os dois formatos
Qual a diferença entre SD-JWT VC e ISO mdoc?
A EUDI Wallet exige os dois formatos de credencial?
Estado das normas e identificadores
O SD-JWT VC é uma norma acabada?
Quais são os identificadores de formato de credencial em OpenID4VP?
Sequência
Que formato deve um serviço só remoto implementar primeiro?
É possível evitar suportar CBOR?
