DCQL skaidrojums: kā pārbaudītājs no maka pieprasa tieši to, kas tam vajadzīgs

Problēma, ko DCQL risina

Rezerves varianta pieprasīšana: claim_sets

claim_sets uzskaita apgalvojumu id grupas prioritātes secībā. Maks atgriež pirmo grupu, ko var pilnībā izpildīt ar to, kas turētājam patiešām ir, tāpēc pārbaudītājam nav jāsūta divi atsevišķi pieprasījumi precīzajam un rezerves gadījumam.

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

Šeit pārbaudītājs dod priekšroku reģistrācijas numuram kopā ar juridisko nosaukumu, bet pieņems arī tikai juridisko nosaukumu, ja turētāja akreditācijas datos nav reģistrācijas numura apgalvojuma.

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

Akreditācijas datu apvienošana: credential_sets

credential_sets darbojas vienu līmeni augstāk nekā claim_sets. Katrs ieraksts uzskaita options, kur katra opcija ir akreditācijas vaicājumu id grupa. Makam jāizpilda viena opcija no katra obligātā ieraksta, kas pārbaudītājam dod AND un OR loģiku starp akreditācijas datiem vienā pieprasījumā.

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

Atbildes piemērs: reģistrācija un bankas konts

Ko maks nosūta

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

Apgalvojumi, ko pārbaudītājs redz pēc validācijas

{
  "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ētājam nav PVN reģistrācijas akreditācijas datu, tāpēc maks izvēlējās otrās kopas otro opciju. Neizmantoto vaicājumu id, šeit vat_registration, vp_token vienkārši nav.

Tikai uzticami izdevēji: trusted_authorities

trusted_authorities sašaurina akreditācijas vaicājumu līdz akreditācijas datiem, kuru izdevēju atbalsta pārbaudītājam uzticama iestāde. Katram ierakstam ir tips un vērtību saraksts: aki iestādes atslēgas identifikatoram, etsi_tl ETSI uzticamo sarakstam vai openid_federation federācijas uzticības enkuram. Maks piedāvā tikai atbilstošus akreditācijas datus.

Piemērs: reģistrācija no saraksta izdevēja

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

Atbildes piemērs: tikai saraksta izdevēja akreditācijas dati

Ko maks nosūta

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

Apgalvojumi, ko pārbaudītājs redz pēc validācijas

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

Turētājam bija arī reģistrācijas akreditācijas dati no izdevēja ārpus saraksta, taču maks tos nepiedāvāja. trusted_authorities ir filtrs makam, nevis garantija: validējot prezentāciju, pārbaudītājs pats pārbauda izdevēju pret uzticamo sarakstu.

Vērtības atbilstība: claims.values

Apgalvojuma vaicājumā var būt values, virkņu, veselu skaitļu vai Būla vērtību saraksts. Maks atgriež apgalvojumu tikai tad, ja tā tips un vērtība precīzi atbilst kādai no tām, tāpēc pārbaudītājs var pārbaudīt nosacījumu, iepriekš neko citu nepieprasot.

Piemērs: tikai Nīderlandē vai Beļģijā reģistrēti uzņēmumi

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

Atbildes piemērs: Nīderlandes uzņēmums

Ko maks nosūta

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

Apgalvojumi, ko pārbaudītājs redz pēc validācijas

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

Vācijas uzņēmuma akreditācijas datos ir registration_country "DE", tāpēc tie neizpilda vaicājumu un makam par tiem nav ko atgriezt. Pārbaudītājam tomēr jāpārbauda vērtība validētajos apgalvojumos, nevis jāpaļaujas uz maka filtrēšanu.

DCQL statuss šodien

• DCQL ir definēts pašā OpenID4VP specifikācijā, nevis kā atsevišķs dokuments, un ir bijis daļa no melnraksta kopš brīža, kad mehānisms tika ieviests, lai aizstātu agrāko atkarību no DIF Presentation Exchange OpenID4VP pieprasījumiem.
• EUDI Wallet Architecture and Reference Framework nosaka OpenID4VP kā prezentācijas protokolu un līdz ar to DCQL kā vaicājumu mehānismu, kas ekosistēmas paļāvīgajām pusēm un makiem būtu jāatbalsta.
• Maku un pārbaudītāju atsauces implementācijas programmā EUDI Wallet Reference Implementation ir vienojušās par DCQL, tāpēc jaunām uzņēmumu maku integrācijām, kas šodien tiek veidotas uz OpenID4VP, prezentācijas pieprasījumu vaicājumu formātam būtu jāparedz DCQL, nevis Presentation Exchange.

Biežāk uzdotie jautājumi

Šai lapai ir informatīvs raksturs, un tā nav juridiska konsultācija. Autoritatīvas vadlīnijas meklējiet tieši OpenID Foundation un Eiropas Komisijā.