DCQL paaiškinimas: kaip tikrintojas prašo piniginės tiksliai to, ko reikia

Kokią problemą sprendžia DCQL

Atsarginis variantas: claim_sets

claim_sets išvardija duomenų id grupes pagal pageidavimo eilę. Piniginė grąžina pirmąją grupę, kurią gali visiškai patenkinti iš to, ką turėtojas iš tikrųjų turi, todėl tikrintojui nereikia siųsti dviejų atskirų užklausų tiksliam ir atsarginiam atvejui.

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

Čia tikrintojas pageidauja registracijos numerio ir teisinio pavadinimo, bet priims ir vien teisinį pavadinimą, jei turėtojo kredenciale nėra registracijos numerio duomens.

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

Kredencialų derinimas: credential_sets

credential_sets veikia vienu lygiu aukščiau nei claim_sets. Kiekviename įraše nurodomi options, kur kiekvienas variantas yra kredencialų užklausų id grupė. Piniginė turi patenkinti po vieną kiekvieno privalomo įrašo variantą, todėl tikrintojas vienoje užklausoje gali taikyti IR bei ARBA logiką keliems kredencialams.

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

Atsakymo pavyzdys: registracija ir banko sąskaita

Ką siunčia piniginė

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

Duomenys, kuriuos tikrintojas mato po patvirtinimo

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

Turėtojas neturi PVM registracijos kredencialo, todėl piniginė pasirinko antrojo rinkinio antrąjį variantą. Nepanaudotų užklausų id, šiuo atveju vat_registration, vp_token tiesiog nėra.

Tik patikimi išdavėjai: trusted_authorities

trusted_authorities susiaurina kredencialo užklausą iki kredencialų, kurių išdavėją patvirtina tikrintojo pasitikima institucija. Kiekvienas įrašas turi tipą ir reikšmių sąrašą: aki institucijos rakto identifikatoriui, etsi_tl ETSI patikimų sąrašui arba openid_federation federacijos pasitikėjimo inkarui. Piniginė siūlo tik atitinkančius kredencialus.

Pavyzdys: registracija iš sąraše esančio išdavėjo

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

Atsakymo pavyzdys: tik sąraše esančio išdavėjo kredencialas

Ką siunčia piniginė

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

Duomenys, kuriuos tikrintojas mato po patvirtinimo

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

Turėtojas turėjo ir registracijos kredencialą iš sąraše nesančio išdavėjo, tačiau piniginė jo nepasiūlė. trusted_authorities yra filtras piniginei, o ne garantija: tikrindamas pateiktį, tikrintojas pats vis tiek patikrina išdavėją pagal patikimų sąrašą.

Reikšmės atitikimas: claims.values

Duomenų užklausoje gali būti values, eilučių, sveikųjų skaičių arba loginių reikšmių sąrašas. Piniginė grąžina duomenį tik tada, kai jo tipas ir reikšmė tiksliai atitinka vieną iš jų, todėl tikrintojas gali patikrinti sąlygą, prieš tai neprašydamas nieko kito.

Pavyzdys: tik Nyderlanduose arba Belgijoje registruotos įmonės

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

Atsakymo pavyzdys: Nyderlandų įmonė

Ką siunčia piniginė

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

Duomenys, kuriuos tikrintojas mato po patvirtinimo

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

Vokietijos įmonės kredenciale registration_country yra "DE", todėl jis netenkina užklausos ir piniginė neturi ką grąžinti. Tikrintojas vis tiek turėtų patikrinti reikšmę patvirtintuose duomenyse, o ne pasikliauti piniginės filtravimu.

DCQL padėtis šiandien

• DCQL apibrėžta pačioje OpenID4VP specifikacijoje, o ne atskirame dokumente, ir yra projekto dalis nuo tada, kai šis mechanizmas buvo įvestas pakeisti ankstesnę OpenID4VP užklausų priklausomybę nuo DIF Presentation Exchange.
• EUDI Wallet Architecture and Reference Framework nurodo OpenID4VP kaip pateikimo protokolą, o kartu ir DCQL kaip užklausų mechanizmą, kurį turėtų palaikyti ekosistemos pasikliaujančiosios šalys ir piniginės.
• Piniginių ir tikrintojų etaloniniai diegimai EUDI Wallet Reference Implementation programoje susivienijo ties DCQL, todėl naujos verslo piniginių integracijos, šiandien kuriamos pagal OpenID4VP, turėtų pateikimo užklausoms numatyti DCQL, o ne Presentation Exchange.

Dažnai užduodami klausimai

Šis puslapis yra informacinio pobūdžio ir nėra teisinė konsultacija. Autoritetingų nurodymų kreipkitės tiesiogiai į OpenID Foundation ir Europos Komisiją.