DCQL spiegato: come un verificatore chiede a un wallet esattamente ciò che gli serve

Il problema che DCQL risolve

Prevedere un'alternativa: claim_sets

claim_sets elenca gruppi di id di attributi in ordine di preferenza. Il wallet restituisce il primo gruppo che può soddisfare interamente con ciò che il titolare possiede davvero, evitando al verificatore di inviare due richieste separate per il caso preciso e per quello 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"]
      ]
    }
  ]
}

Qui il verificatore preferisce il numero di registrazione insieme alla ragione sociale, ma accetta la sola ragione sociale se la credenziale del titolare non contiene l'attributo del numero di registrazione.

{
  "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."
}

Combinare credenziali: credential_sets

credential_sets opera un livello sopra claim_sets. Ogni voce elenca delle options, dove ogni opzione è un gruppo di id di credential query. Il wallet deve soddisfare un'opzione per ogni voce obbligatoria, il che offre al verificatore una logica AND e OR tra credenziali in un'unica richiesta.

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

Esempio di risposta: registrazione più conto bancario

Cosa invia il wallet

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

Attributi visibili al verificatore dopo la validazione

{
  "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."
  }
}

Il titolare non ha una credenziale di partita IVA, quindi il wallet ha scelto la seconda opzione del secondo set. Gli id di query non utilizzati, qui vat_registration, semplicemente non compaiono in vp_token.

Solo emittenti affidabili: trusted_authorities

trusted_authorities limita una credential query alle credenziali il cui emittente è garantito da un'autorità di cui il verificatore si fida. Ogni voce ha un tipo e un elenco di valori: aki per un authority key identifier, etsi_tl per una trusted list ETSI oppure openid_federation per un trust anchor di federazione. Il wallet propone solo le credenziali corrispondenti.

Esempio pratico: una registrazione da un emittente in lista

{
  "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"] }
      ]
    }
  ]
}

Esempio di risposta: solo la credenziale dell'emittente in lista

Cosa invia il wallet

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

Attributi visibili al verificatore dopo la validazione

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

Il titolare aveva anche una credenziale di registrazione di un emittente non in lista, ma il wallet non l'ha proposta. trusted_authorities è un filtro per il wallet, non una garanzia: il verificatore controlla comunque in autonomia l'emittente rispetto alla lista di fiducia quando valida la presentazione.

Verificare un valore: claims.values

Una claim query può includere values, un elenco di stringhe, interi o booleani. Il wallet restituisce l'attributo solo se tipo e valore corrispondono esattamente a uno di essi, così un verificatore può controllare una condizione senza prima chiedere altro.

Esempio pratico: solo imprese registrate nei Paesi Bassi o in Belgio

{
  "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"]
        }
      ]
    }
  ]
}

Esempio di risposta: un'impresa olandese

Cosa invia il wallet

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

Attributi visibili al verificatore dopo la validazione

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

La credenziale di un'impresa tedesca ha registration_country "DE", quindi non soddisfa la query e il wallet non ha nulla da restituire. Il verificatore dovrebbe comunque controllare il valore negli attributi validati anziché affidarsi al filtro del wallet.

A che punto è DCQL oggi

• DCQL è definito all'interno della specifica OpenID4VP stessa, non in un documento separato, e fa parte della bozza da quando il meccanismo è stato introdotto per sostituire la precedente dipendenza da DIF Presentation Exchange nelle richieste OpenID4VP.
• L'EUDI Wallet Architecture and Reference Framework indica OpenID4VP come protocollo di presentazione e, con esso, DCQL come meccanismo di query che relying party e wallet dell'ecosistema devono supportare.
• Le implementazioni di riferimento di wallet e verificatori del programma EUDI Wallet Reference Implementation sono convergite su DCQL, quindi le nuove integrazioni di business wallet basate su OpenID4VP dovrebbero oggi presupporre DCQL, e non Presentation Exchange, come formato di query per le richieste di presentazione.

Domande frequenti

Questa pagina ha scopo informativo e non costituisce consulenza legale. Per indicazioni autorevoli rivolgersi direttamente alla OpenID Foundation e alla Commissione europea.