DCQL explicado: como um verificador pede a uma carteira exatamente o que precisa

O problema que o DCQL resolve

Pedir uma alternativa: claim_sets

claim_sets lista grupos de ids de atributos por ordem de preferência. A carteira devolve o primeiro grupo que consegue satisfazer integralmente com o que o titular efetivamente tem, evitando que o verificador tenha de enviar dois pedidos separados, um para o caso preciso e outro para o caso alternativo.

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ],
      "claim_sets": [
        ["reg_no", "legal_name"],
        ["legal_name"]
      ]
    }
  ]
}

Aqui o verificador prefere um número de registo juntamente com a denominação social, mas aceita apenas a denominação social se a credencial do titular não contiver um atributo de número de registo.

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V."
}

Combinar credenciais: credential_sets

credential_sets funciona um nível acima de claim_sets. Cada entrada lista options, em que cada opção é um grupo de ids de consultas de credenciais. A carteira tem de satisfazer uma opção de cada entrada obrigatória, o que dá ao verificador lógica AND e OR entre credenciais num único pedido.

"credential_sets": [
  { "options": [["company_registration"]] },
  { "options": [["vat_registration"], ["bank_account"]] }
]

Exemplo de resposta: registo mais conta bancária

O que a carteira envia

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ],
    "bank_account": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ]
  }
}

Atributos que o verificador vê após a validação

{
  "company_registration": {
    "vct": "urn:eudi:business:company-registration:1",
    "registration_number": "12345678",
    "legal_name": "Example Logistics B.V."
  },
  "bank_account": {
    "vct": "urn:eudi:business:bank-account:1",
    "iban": "NL91ABNA0417164300",
    "account_holder": "Example Logistics B.V."
  }
}

O titular não tem uma credencial de registo de IVA, por isso a carteira escolheu a segunda opção do segundo conjunto. Os ids de consulta que não foram usados, neste caso vat_registration, simplesmente não aparecem em vp_token.

Apenas emissores de confiança: trusted_authorities

trusted_authorities restringe uma consulta de credencial a credenciais cujo emissor é suportado por uma autoridade em que o verificador confia. Cada entrada tem um type e uma lista de values: aki para um identificador de chave da autoridade, etsi_tl para uma lista de confiança ETSI, ou openid_federation para uma âncora de confiança de federação. A carteira só propõe credenciais que correspondam.

Exemplo prático: um registo de um emissor listado

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "trusted_authorities": [
        {
          "type": "etsi_tl",
          "values": ["https://ec.europa.eu/tools/lotl/eu-lotl.xml"]
        }
      ],
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ]
    }
  ]
}

Exemplo de resposta: apenas a credencial do emissor listado

O que a carteira envia

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: registration_number>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

Atributos que o verificador vê após a validação

{
  "vct": "urn:eudi:business:company-registration:1",
  "registration_number": "12345678",
  "legal_name": "Example Logistics B.V."
}

O titular tinha também uma credencial de registo de um emissor não listado, mas a carteira não a propôs. trusted_authorities é um filtro para a carteira, não uma garantia: o verificador continua a confirmar o emissor na lista de confiança quando valida a apresentação.

Corresponder a um valor: claims.values

Uma consulta de atributo pode incluir values, uma lista de strings, inteiros ou booleanos. A carteira só devolve o atributo quando o seu tipo e valor correspondem exatamente a um deles, pelo que um verificador pode verificar uma condição sem ter de pedir primeiro qualquer outra informação.

Exemplo prático: apenas empresas registadas nos Países Baixos ou na Bélgica

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "legal_name", "path": ["legal_name"] },
        {
          "id": "reg_country",
          "path": ["registration_country"],
          "values": ["NL", "BE"]
        }
      ]
    }
  ]
}

Exemplo de resposta: uma empresa neerlandesa

O que a carteira envia

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<disclosure: registration_country>~<key binding JWT>"
    ]
  }
}

Atributos que o verificador vê após a validação

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V.",
  "registration_country": "NL"
}

A credencial de uma empresa alemã tem registration_country "DE", por isso não satisfaz a consulta e a carteira não tem nada a devolver para ela. O verificador deve, ainda assim, verificar o valor nos atributos validados em vez de confiar na filtragem da carteira.

O ponto de situação do DCQL

• O DCQL é definido dentro da própria especificação OpenID4VP, e não num documento separado, e faz parte do rascunho desde que o mecanismo foi introduzido para substituir uma dependência anterior do DIF Presentation Exchange nos pedidos OpenID4VP.
• O EUDI Wallet Architecture and Reference Framework especifica o OpenID4VP como protocolo de apresentação e, com ele, o DCQL como o mecanismo de consulta que se espera que as partes confiantes e as carteiras do ecossistema suportem.
• As implementações de referência de carteiras e verificadores no programa EUDI Wallet Reference Implementation convergiram para o DCQL, pelo que as novas integrações de carteiras empresariais desenvolvidas hoje sobre OpenID4VP devem assumir o DCQL, e não o Presentation Exchange, como formato de consulta para pedidos de apresentação.

Perguntas frequentes

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.