DCQL explicado: como um verificador pede a uma carteira exatamente o que precisa
O DCQL, Digital Credentials Query Language, é a forma acordada de uma organização dizer a uma wallet de que credenciais precisa e de que dados dentro delas. É o que transforma um pedido como "prove que a sua empresa está registada nos Países Baixos" em algo que todas as wallets conformes entendem, sem uma integração separada por wallet.
O problema que o DCQL resolve
Uma business wallet guarda credenciais de muitos tipos, emitidas por entidades diferentes em países diferentes e guardadas em formatos técnicos diferentes. Uma organização que só precisa de confirmar um número de registo e uma denominação legal não tem forma portável de pedir exatamente isso. Acaba por ficar com a credencial inteira, com tudo o que ela contém, ou por construir uma integração separada para cada wallet com que se cruza.
O DCQL resolve o lado do pedido. Um pedido normalizado indica as credenciais pretendidas e os dados concretos pretendidos de cada uma. A wallet compara-o com aquilo que o titular tem realmente, mostra ao titular o que está a ser pedido e divulga apenas isso. O verificador obtém uma resposta previsível, independentemente da wallet que o titular usa.
1. Verificador
Pede exatamente as credenciais e os dados de que precisa
2. Carteira
Determina quais das credenciais guardadas correspondem ao pedido
3. Titular
Vê o que está a ser pedido e aprova a divulgação apenas disso
4. Verificador
Recebe os dados aprovados, e nada mais
O que um verificador pode pedir
Um pedido é uma lista curta do que é necessário. Pode indicar uma credencial ou várias e, para cada uma, pode indicar os dados concretos pretendidos em vez do conteúdo todo. Três opções adicionais cobrem quase todos os casos reais: alternativas, combinações e um limite sobre que emissores são aceitáveis.
- Que credenciais são necessárias e que dados dentro de cada uma.
- Alternativas aceitáveis, por ordem de preferência, para titulares que não têm tudo.
- Combinações, para que um pedido possa exigir uma credencial e uma de outras duas.
- Uma restrição a emissores que constem de uma trusted list oficial, para que credenciais de terceiros nunca sejam propostas.
Pedir uma alternativa
Nem todos os titulares têm a mesma credencial. Um verificador pode indicar o que preferia e o que ainda assim aceitaria, por ordem, e a wallet usa a melhor opção que o titular consegue realmente satisfazer. Assim evita-se uma segunda ronda de pedidos e evita-se recusar um cliente a quem falta apenas o pormenor mais desejável.
1. Preferido
Usado quando a credencial contém ambos
2. Alternativa
Usado apenas quando a primeira opção não pode ser satisfeita
Aqui o verificador preferia um número de registo em conjunto com a denominação legal, mas aceita apenas a denominação legal quando a credencial do titular não contém um número de registo.
Combinar credenciais num único pedido
As verificações de onboarding raramente assentam num único documento. Um verificador pode exigir uma credencial e aceitar, em conjunto com ela, uma de outras duas, tudo num só pedido, pelo que o titular aprova uma única vez e o verificador obtém uma resposta completa num só passo.
Obrigatório
Registo comercial
Um de
Registo de IVA
Um de
Atestado de conta bancária
É exigido um registo comercial. Além disso, serve um registo de IVA ou uma atestação de conta bancária, e ao titular basta ter uma delas.
Aceitar apenas emissores de confiança
Um verificador pode restringir um pedido a credenciais cujo emissor conste de uma trusted list oficial. Credenciais de qualquer outra origem nem sequer são propostas ao titular, pelo que uma imitação autoemitida não chega sequer à verificação.
O verificador diz: apenas de emissores que constem de uma trusted list oficial da UE
Credencial de registo de um emissor listado
O emissor consta da trusted list
✓ Proposta ao titular
Credencial de registo de um emissor não listado
O emissor não consta da trusted list
✗ Não é proposta ao titular
Isto é um filtro na wallet, não uma garantia por si só. O verificador continua a confrontar o emissor com a trusted list quando valida o que recebeu.
O ponto de situação do DCQL
- O DCQL faz parte da própria especificação OpenID4VP e não é um documento separado, e substituiu uma dependência anterior do DIF Presentation Exchange.
- O Architecture and Reference Framework da EUDI Wallet indica o OpenID4VP como protocolo de apresentação e o DCQL com ele, pelo que se espera que as wallets e os verificadores do ecossistema o suportem.
- As wallets e os verificadores de referência do programa EUDI Wallet convergiram para o DCQL, pelo que uma integração de business wallet iniciada hoje deve assumi-lo em vez da alternativa mais antiga.
O que isto significa para si
Verificador
Um único formato de pedido cobre todas as wallets e só recebe os dados que pediu, ou seja, menos dados para guardar, proteger e justificar.
Titular
Vê exatamente o que lhe está a ser pedido antes de aprovar, e nada para além disso sai da sua wallet.
Emissor
As credenciais que emite continuam úteis para verificações parciais, pelo que uma credencial pode servir muitos fins diferentes.
Aprofundamento técnico
Esta página explica o que a tecnologia faz e a quem diz respeito. A nossa documentação para programadores cobre a implementação em si: as mensagens, os campos e os exemplos práticos de que uma equipa de integração precisa.
Ler a documentação técnicaTermos relacionados
Perguntas frequentes
Em que difere o DCQL do DIF Presentation Exchange?
Ambos são formas de um verificador descrever o que pretende de uma wallet. O Presentation Exchange é o mais antigo e o mais abrangente dos dois, concebido para funcionar em vários protocolos. O DCQL é deliberadamente mais reduzido e está definido dentro do próprio OpenID4VP. O ecossistema EUDI Wallet normalizou o DCQL, por isso é esse que deve orientar os planos para o mercado europeu.
Um único pedido pode abranger mais do que uma credencial?
Sim, e essa é uma das razões por que existe. Um verificador pode pedir um registo comercial e uma atestação de conta bancária num único pedido, ou aceitar uma de duas alternativas, e o titular aprova tudo num só passo em vez de ser questionado duas vezes.
O que acontece se o titular não tiver tudo o que foi pedido?
O verificador pode indicar alternativas aceitáveis, por ordem de preferência, e a wallet usa a melhor que o titular consegue realmente satisfazer. Assim, um verificador pode pedir um número de registo exato onde ele existe e contentar-se com a denominação legal onde não existe, sem enviar um segundo pedido nem recusar o titular.
O DCQL é específico da EUDI Wallet?
Não. O DCQL faz parte do OpenID4VP e qualquer implementação desse protocolo pode usá-lo. O ecossistema EUDI Wallet é um adotante de relevo: o Architecture and Reference Framework indica o OpenID4VP com DCQL como a forma de apresentar credenciais, e é por isso que importa a quem desenvolve para o mercado europeu.
Isto ajuda na minimização de dados ao abrigo do GDPR?
Torna o mínimo explícito. O pedido indica que dados são necessários, o titular vê essa lista antes de aprovar e a wallet não divulga nada para além dela. Isso transforma a minimização de dados de uma promessa num limite imposto pela própria troca, o que é muito mais fácil de demonstrar.
Fontes
Esta página tem caráter meramente informativo e não constitui aconselhamento jurídico. Para orientações oficiais, consulte diretamente a OpenID Foundation e a Comissão Europeia.