DCQL forklaret: sådan beder en verifier en wallet om præcis det, den har brug for

Problemet, DCQL løser

Bed om et alternativ: claim_sets

claim_sets angiver grupper af claim-id'er i prioriteret rækkefølge. Wallet'en returnerer den første gruppe, den fuldt ud kan opfylde med det, indehaveren faktisk har, så verifieren ikke behøver sende to separate anmodninger for et præcist tilfælde og et alternativt tilfælde.

{
  "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 foretrækker verifieren et registreringsnummer plus det juridiske navn, men accepterer det juridiske navn alene, hvis indehaverens credential ikke indeholder et claim med 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."
}

Kombination af credentials: credential_sets

credential_sets virker ét niveau over claim_sets. Hver post angiver options, hvor hver option er en gruppe af credential query-id'er. Wallet'en skal opfylde én option i hver påkrævet post, hvilket giver en verifier AND- og OR-logik på tværs af credentials i én anmodning.

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

Eksempel på svar: registrering plus bankkonto

Det, wallet'en sender

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

Claims, verifieren ser efter 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."
  }
}

Indehaveren har ingen credential for momsregistrering, så wallet'en valgte den anden option i det andet sæt. Query-id'er, der ikke blev brugt, her vat_registration, er simpelthen fraværende i vp_token.

Kun betroede udstedere: trusted_authorities

trusted_authorities begrænser en credential query til credentials, hvis udsteder er understøttet af en myndighed, som verifieren har tillid til. Hver post har en type og en liste af values: aki for en authority key identifier, etsi_tl for en ETSI-tillidsliste eller openid_federation for et trust anchor i en føderation. Wallet'en tilbyder kun credentials, der matcher.

Gennemgået eksempel: en registrering fra en listet udsteder

{
  "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: kun den listede udsteders credential

Det, wallet'en sender

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

Claims, verifieren ser efter validering

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

Indehaveren havde også en registreringscredential fra en ikke-listet udsteder, men wallet'en tilbød den ikke. trusted_authorities er et filter for wallet'en, ikke en garanti: verifieren kontrollerer stadig selv udstederen mod tillidslisten, når den validerer præsentationen.

Match på en værdi: claims.values

En claim query kan indeholde values, en liste af strenge, heltal eller booleans. Wallet'en returnerer kun claimet, når dets type og værdi præcist matcher en af dem, så en verifier kan kontrollere en betingelse uden først at bede om noget andet.

Gennemgået eksempel: kun virksomheder registreret i Nederlandene eller Belgien

{
  "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: en hollandsk virksomhed

Det, wallet'en sender

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

Claims, verifieren ser efter validering

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

En tysk virksomheds credential har registration_country "DE", så den opfylder ikke forespørgslen, og wallet'en har intet at returnere for den. Verifieren bør stadig kontrollere værdien i de validerede claims i stedet for at stole på wallet'ens filtrering.

Hvor DCQL står i dag

• DCQL er defineret i selve OpenID4VP-specifikationen, ikke som et separat dokument, og har været en del af udkastet, siden mekanismen blev indført for at erstatte en tidligere afhængighed af DIF Presentation Exchange i OpenID4VP-anmodninger.
• EUDI Wallet Architecture and Reference Framework angiver OpenID4VP som præsentationsprotokol og dermed DCQL som den forespørgselsmekanisme, relying parties og wallets i økosystemet forventes at understøtte.
• Referenceimplementeringer af wallets og verifiers i programmet EUDI Wallet Reference Implementation er konvergeret mod DCQL, så nye business wallet-integrationer, der bygges mod OpenID4VP i dag, bør gå ud fra DCQL frem for Presentation Exchange som forespørgselsformat for præsentationsanmodninger.

Ofte stillede spørgsmål

Denne side er udelukkende til orientering og udgør ikke juridisk rådgivning. Kontakt OpenID Foundation og Europa-Kommissionen direkte for autoritativ vejledning.