DCQL selitettynä: näin todentaja pyytää lompakolta juuri sen, mitä tarvitsee

Ongelma, jonka DCQL ratkaisee

Varavaihtoehdon pyytäminen: claim_sets

claim_sets luettelee tieto-id-ryhmiä suosituimmuusjärjestyksessä. Lompakko palauttaa ensimmäisen ryhmän, jonka se voi täyttää kokonaan haltijan todellisilla tiedoilla, joten todentajan ei tarvitse lähettää kahta erillistä pyyntöä tarkalle tapaukselle ja varatapaukselle.

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

Tässä todentaja haluaa ensisijaisesti rekisterinumeron ja virallisen nimen, mutta hyväksyy pelkän virallisen nimen, jos haltijan todisteessa ei ole rekisterinumerotietoa.

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

Todisteiden yhdistäminen: credential_sets

credential_sets toimii tasoa ylempänä kuin claim_sets. Jokainen kohta luettelee options-vaihtoehtoja, joista kukin on ryhmä todistekyselyjen id:itä. Lompakon on täytettävä yksi vaihtoehto jokaisesta pakollisesta kohdasta, mikä antaa todentajalle JA- ja TAI-logiikan todisteiden välillä yhdessä pyynnössä.

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

Esimerkkivastaus: rekisteröinti ja pankkitili

Mitä lompakko lähettää

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

Tiedot, jotka todentaja näkee validoinnin jälkeen

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

Haltijalla ei ole ALV-rekisteröintitodistetta, joten lompakko valitsi toisen joukon toisen vaihtoehdon. Käyttämättömät kyselyn id:t, tässä vat_registration, yksinkertaisesti puuttuvat vp_tokenista.

Vain luotetut myöntäjät: trusted_authorities

trusted_authorities rajaa todistekyselyn todisteisiin, joiden myöntäjän taustalla on todentajan luottama taho. Jokaisella kohdalla on tyyppi ja arvoluettelo: aki valtuutetun tahon avaintunnisteelle, etsi_tl ETSI-luotettujen listalle tai openid_federation federaation luottamusankkurille. Lompakko tarjoaa vain vastaavia todisteita.

Esimerkki: rekisteröinti listatulta myöntäjältä

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

Esimerkkivastaus: vain listatun myöntäjän todiste

Mitä lompakko lähettää

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

Tiedot, jotka todentaja näkee validoinnin jälkeen

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

Haltijalla oli myös rekisteröintitodiste listaamattomalta myöntäjältä, mutta lompakko ei tarjonnut sitä. trusted_authorities on lompakon suodatin, ei takuu: todentaja tarkistaa silti itse myöntäjän luotettujen listaa vasten validoidessaan esityksen.

Arvon täsmäytys: claims.values

Tietokyselyssä voi olla values eli luettelo merkkijonoja, kokonaislukuja tai totuusarvoja. Lompakko palauttaa tiedon vain, jos sen tyyppi ja arvo vastaavat täsmälleen jotakin niistä, joten todentaja voi tarkistaa ehdon pyytämättä ensin mitään muuta.

Esimerkki: vain Alankomaihin tai Belgiaan rekisteröidyt yritykset

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

Esimerkkivastaus: hollantilainen yritys

Mitä lompakko lähettää

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

Tiedot, jotka todentaja näkee validoinnin jälkeen

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

Saksalaisen yrityksen todisteessa registration_country on "DE", joten se ei täytä kyselyä eikä lompakolla ole siitä mitään palautettavaa. Todentajan kannattaa silti tarkistaa arvo validoiduista tiedoista eikä luottaa lompakon suodatukseen.

DCQL:n tilanne nyt

• DCQL on määritelty itse OpenID4VP-spesifikaatiossa eikä erillisessä dokumentissa, ja se on ollut osa luonnosta siitä lähtien, kun mekanismi otettiin käyttöön korvaamaan OpenID4VP-pyyntöjen aiempi riippuvuus DIF Presentation Exchangesta.
• EUDI Wallet Architecture and Reference Framework määrittää OpenID4VP:n esitysprotokollaksi ja sen myötä DCQL:n kyselymekanismiksi, jota ekosysteemin luottavien osapuolten ja lompakoiden odotetaan tukevan.
• EUDI Wallet Reference Implementation -ohjelman lompakko- ja todentajatoteutukset ovat vakiintuneet DCQL:ään, joten uusien OpenID4VP:hen perustuvien yrityslompakkointegraatioiden kannattaa nyt olettaa esityspyyntöjen kyselymuodoksi DCQL eikä Presentation Exchange.

Usein kysytyt kysymykset

Tämä sivu on tarkoitettu tiedoksi eikä ole oikeudellista neuvontaa. Luotettavaa ohjeistusta saat suoraan OpenID Foundationilta ja Euroopan komissiolta.