DCQL pe înțeles: cum cere un verificator unui portofel exact ce îi trebuie

Problema pe care o rezolvă DCQL

Solicitarea unei alternative: claim_sets

claim_sets enumeră grupuri de id-uri de atribute, în ordinea preferinței. Portofelul returnează primul grup pe care îl poate satisface integral din ceea ce deține efectiv titularul, astfel încât verificatorul nu mai trebuie să trimită două cereri separate, una pentru cazul precis și una pentru cazul alternativ.

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

Aici verificatorul preferă un număr de înregistrare împreună cu denumirea legală, dar acceptă doar denumirea legală dacă credențialul titularului nu conține un atribut cu numărul de înregistrare.

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

Combinarea credențialelor: credential_sets

credential_sets funcționează cu un nivel deasupra claim_sets. Fiecare intrare enumeră options, unde fiecare opțiune este un grup de id-uri de interogări de credențiale. Portofelul trebuie să satisfacă o opțiune din fiecare intrare obligatorie, ceea ce îi oferă verificatorului logică AND și OR între credențiale într-o singură cerere.

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

Exemplu de răspuns: înregistrare plus cont bancar

Ce trimite portofelul

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

Atributele pe care le vede verificatorul după validare

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

Titularul nu are un credențial de înregistrare în scopuri de TVA, așa că portofelul a ales a doua opțiune din al doilea set. Id-urile de interogare nefolosite, aici vat_registration, pur și simplu lipsesc din vp_token.

Doar emitenți de încredere: trusted_authorities

trusted_authorities restrânge o interogare la credențialele al căror emitent este susținut de o autoritate în care verificatorul are încredere. Fiecare intrare are un type și o listă de values: aki pentru un identificator de cheie al autorității (authority key identifier), etsi_tl pentru o listă de încredere ETSI sau openid_federation pentru o ancoră de încredere a unei federații. Portofelul oferă doar credențialele care corespund.

Exemplu practic: o înregistrare de la un emitent listat

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

Exemplu de răspuns: doar credențialul emitentului listat

Ce trimite portofelul

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

Atributele pe care le vede verificatorul după validare

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

Titularul avea și un credențial de înregistrare de la un emitent nelistat, dar portofelul nu l-a oferit. trusted_authorities este un filtru pentru portofel, nu o garanție: verificatorul verifică în continuare el însuși emitentul în lista de încredere atunci când validează prezentarea.

Potrivirea unei valori: claims.values

O interogare de atribut poate conține values, o listă de șiruri de caractere, numere întregi sau valori booleene. Portofelul returnează atributul doar când tipul și valoarea sa corespund exact uneia dintre ele, astfel încât un verificator poate verifica o condiție fără a cere mai întâi altceva.

Exemplu practic: doar companii înregistrate în Țările de Jos sau în Belgia

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

Exemplu de răspuns: o companie olandeză

Ce trimite portofelul

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

Atributele pe care le vede verificatorul după validare

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

Credențialul unei companii germane are registration_country "DE", deci nu satisface interogarea, iar portofelul nu are nimic de returnat pentru acesta. Verificatorul ar trebui totuși să verifice valoarea în atributele validate, în loc să se bazeze pe filtrarea făcută de portofel.

Stadiul actual al DCQL

• DCQL este definit în cadrul specificației OpenID4VP, nu ca document separat, și face parte din draft de când mecanismul a fost introdus pentru a înlocui o dependență anterioară de DIF Presentation Exchange în cererile OpenID4VP.
• EUDI Wallet Architecture and Reference Framework specifică OpenID4VP ca protocol de prezentare și, odată cu acesta, DCQL ca mecanism de interogare pe care părțile care se bazează și portofelele din ecosistem sunt așteptate să îl suporte.
• Implementările de referință pentru portofele și verificatori din programul EUDI Wallet Reference Implementation au convergit spre DCQL, așa că noile integrări de portofele de afaceri construite astăzi pe OpenID4VP ar trebui să considere DCQL, nu Presentation Exchange, drept format de interogare pentru cererile de prezentare.

Întrebări frecvente

Această pagină are caracter informativ și nu constituie consultanță juridică. Pentru îndrumări oficiale, consultați direct OpenID Foundation și Comisia Europeană.