DCQL forklart: slik ber en verifikator en lommebok om nøyaktig det den trenger

Problemet DCQL løser

Be om et reservealternativ: claim_sets

claim_sets lister grupper av opplysnings-id-er i prioritert rekkefølge. Lommeboken returnerer den første gruppen den kan oppfylle fullt ut med det innehaveren faktisk har, slik at verifikatoren slipper å sende to separate forespørsler for et presist tilfelle og et reservetilfelle.

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

Her foretrekker verifikatoren registreringsnummer og juridisk navn, men godtar det juridiske navnet alene hvis innehaverens bevis ikke inneholder en opplysning om registreringsnummer.

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

Kombinere bevis: credential_sets

credential_sets virker ett nivå over claim_sets. Hver oppføring lister options, der hvert alternativ er en gruppe id-er for bevisforespørsler. Lommeboken må oppfylle ett alternativ i hver påkrevde oppføring, noe som gir verifikatoren OG- og ELLER-logikk på tvers av bevis i én enkelt forespørsel.

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

Eksempel på svar: registrering pluss bankkonto

Hva lommeboken sender

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

Opplysninger verifikatoren ser etter validering

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

Innehaveren har ikke noe MVA-registreringsbevis, så lommeboken valgte det andre alternativet i det andre settet. Forespørsels-id-er som ikke ble brukt, her vat_registration, er rett og slett fraværende i vp_token.

Bare pålitelige utstedere: trusted_authorities

trusted_authorities begrenser en bevisforespørsel til bevis der utstederen er støttet av en autoritet verifikatoren stoler på. Hver oppføring har en type og en liste med verdier: aki for en authority key identifier, etsi_tl for en ETSI-tillitsliste eller openid_federation for et tillitsanker i en føderasjon. Lommeboken tilbyr bare bevis som samsvarer.

Eksempel: en registrering fra en oppført utsteder

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

Eksempel på svar: bare beviset fra den oppførte utstederen

Hva lommeboken sender

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

Opplysninger verifikatoren ser etter validering

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

Innehaveren hadde også et registreringsbevis fra en ikke-oppført utsteder, men lommeboken tilbød det ikke. trusted_authorities er et filter for lommeboken, ikke en garanti: verifikatoren kontrollerer likevel selv utstederen mot tillitslisten når den validerer presentasjonen.

Samsvar med en verdi: claims.values

En opplysningsforespørsel kan inneholde values, en liste med strenger, heltall eller boolske verdier. Lommeboken returnerer bare opplysningen når typen og verdien samsvarer nøyaktig med én av dem, slik at en verifikator kan kontrollere en betingelse uten først å be om noe annet.

Eksempel: bare foretak registrert i Nederland eller 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"]
        }
      ]
    }
  ]
}

Eksempel på svar: et nederlandsk foretak

Hva lommeboken sender

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

Opplysninger verifikatoren ser etter validering

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

Beviset til et tysk foretak har registration_country "DE", så det oppfyller ikke forespørselen, og lommeboken har ingenting å returnere for det. Verifikatoren bør likevel kontrollere verdien i de validerte opplysningene i stedet for å stole på lommebokens filtrering.

Hvor DCQL står i dag

• DCQL er definert i selve OpenID4VP-spesifikasjonen, ikke som et eget dokument, og har vært en del av utkastet siden mekanismen ble innført for å erstatte en tidligere avhengighet av DIF Presentation Exchange for OpenID4VP-forespørsler.
• EUDI Wallet Architecture and Reference Framework angir OpenID4VP som presentasjonsprotokoll og dermed DCQL som forespørselsmekanismen tillitsparter og lommebøker i økosystemet forventes å støtte.
• Referanseimplementasjoner av lommebøker og verifikatorer i EUDI Wallet Reference Implementation-programmet har samlet seg om DCQL. Nye integrasjoner av bedriftslommebøker som bygges mot OpenID4VP i dag, bør derfor forutsette DCQL og ikke Presentation Exchange som forespørselsformat for presentasjonsforespørsler.

Ofte stilte spørsmål

Denne siden er kun til informasjon og utgjør ikke juridisk rådgivning. For autoritativ veiledning, kontakt OpenID Foundation og Europakommisjonen direkte.