DCQL razložen: kako preveritelj od denarnice zahteva natanko to, kar potrebuje

Težava, ki jo rešuje DCQL

Nadomestna možnost: claim_sets

claim_sets navaja skupine id podatkov po vrstnem redu prednosti. Denarnica vrne prvo skupino, ki jo lahko v celoti izpolni s tem, kar imetnik dejansko ima, zato preveritelju ni treba pošiljati dveh ločenih zahtev za natančen in nadomestni primer.

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

Tu preveritelj daje prednost matični številki skupaj s firmo, sprejme pa tudi samo firmo, če imetnikova poverilnica ne vsebuje podatka o matični številki.

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

Kombiniranje poverilnic: credential_sets

credential_sets deluje eno raven višje kot claim_sets. Vsak vnos navaja options, pri čemer je vsaka možnost skupina id poizvedb po poverilnicah. Denarnica mora izpolniti eno možnost vsakega obveznega vnosa, kar preveritelju omogoča logiko IN in ALI prek več poverilnic v eni sami zahtevi.

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

Primer odgovora: registracija in bančni račun

Kaj pošlje denarnica

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

Podatki, ki jih preveritelj vidi po validaciji

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

Imetnik nima poverilnice o registraciji za DDV, zato je denarnica izbrala drugo možnost drugega nabora. Id poizvedb, ki niso bili uporabljeni, tu vat_registration, v vp_token preprosto manjkajo.

Samo zaupanja vredni izdajatelji: trusted_authorities

trusted_authorities omeji poizvedbo na poverilnice, katerih izdajatelja podpira organ, ki mu preveritelj zaupa. Vsak vnos ima type in seznam values: aki za identifikator ključa organa, etsi_tl za seznam zaupanja ETSI ali openid_federation za sidro zaupanja federacije. Denarnica ponudi samo ustrezne poverilnice.

Praktični primer: registracija od izdajatelja s seznama

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

Primer odgovora: samo poverilnica izdajatelja s seznama

Kaj pošlje denarnica

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

Podatki, ki jih preveritelj vidi po validaciji

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

Imetnik je imel tudi poverilnico o registraciji od izdajatelja, ki ni na seznamu, vendar je denarnica ni ponudila. trusted_authorities je filter za denarnico, ne jamstvo: preveritelj pri validaciji predstavitve izdajatelja še vedno sam preveri glede na seznam zaupanja.

Ujemanje vrednosti: claims.values

Poizvedba po podatku lahko vsebuje values, seznam nizov, celih števil ali logičnih vrednosti. Denarnica podatek vrne samo, če se njegov tip in vrednost natančno ujemata z eno od njih, zato lahko preveritelj preveri pogoj, ne da bi prej zahteval kar koli drugega.

Praktični primer: samo podjetja, registrirana na Nizozemskem ali v Belgiji

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

Primer odgovora: nizozemsko podjetje

Kaj pošlje denarnica

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

Podatki, ki jih preveritelj vidi po validaciji

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

Poverilnica nemškega podjetja ima registration_country "DE", zato ne izpolnjuje poizvedbe in denarnica zanjo nima česa vrniti. Preveritelj naj vrednost kljub temu preveri v validiranih podatkih in se ne zanaša na filtriranje v denarnici.

Kje je DCQL danes

• DCQL je opredeljen v sami specifikaciji OpenID4VP, ne kot ločen dokument, in je del osnutka, odkar je bil mehanizem uveden kot nadomestilo za prejšnjo odvisnost zahtev OpenID4VP od DIF Presentation Exchange.
• EUDI Wallet Architecture and Reference Framework določa OpenID4VP kot protokol predstavitve in z njim DCQL kot poizvedbeni mehanizem, ki naj ga podpirajo zanašajoče se stranke in denarnice v ekosistemu.
• Referenčne implementacije denarnic in preveriteljev v programu EUDI Wallet Reference Implementation so se poenotile okoli DCQL. Nove integracije poslovnih denarnic, zgrajene danes na OpenID4VP, naj zato kot obliko poizvedb v zahtevah za predstavitev predvidijo DCQL in ne Presentation Exchange.

Pogosta vprašanja

Ta stran je informativne narave in ne predstavlja pravnega nasveta. Za verodostojne smernice se obrnite neposredno na OpenID Foundation in Evropsko komisijo.