DCQL uitgelegd: hoe een verifier een wallet om precies de juiste gegevens vraagt

Het probleem dat DCQL oplost

Een terugvaloptie vragen: claim_sets

claim_sets somt groepen claim-id's op in volgorde van voorkeur. De wallet geeft de eerste groep terug waaraan hij volledig kan voldoen met wat de houder daadwerkelijk heeft. De verifier hoeft dus geen twee aparte verzoeken te sturen voor een exacte en een terugvalsituatie.

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

Hier heeft de verifier liever een registratienummer plus de statutaire naam, maar accepteert hij ook alleen de statutaire naam als de credential van de houder geen claim met een registratienummer bevat.

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

Credentials combineren: credential_sets

credential_sets werkt een niveau hoger dan claim_sets. Elk item somt options op, waarbij elke optie een groep credential query id's is. De wallet moet voldoen aan één optie van elk verplicht item. Zo krijgt een verifier EN- en OF-logica over credentials heen in één verzoek.

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

Voorbeeldantwoord: registratie plus bankrekening

Wat de wallet verstuurt

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

Claims die de verifier na validatie ziet

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

De houder heeft geen credential voor btw-registratie, dus de wallet koos de tweede optie van de tweede set. Query-id's die niet zijn gebruikt, hier vat_registration, ontbreken gewoon in vp_token.

Alleen vertrouwde issuers: trusted_authorities

trusted_authorities beperkt een credential query tot credentials waarvan de issuer wordt gedekt door een autoriteit die de verifier vertrouwt. Elk item heeft een type en een lijst values: aki voor een authority key identifier, etsi_tl voor een ETSI trusted list, of openid_federation voor een trust anchor in een federatie. De wallet biedt alleen credentials aan die daaraan voldoen.

Uitgewerkt voorbeeld: een registratie van een vermelde issuer

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

Voorbeeldantwoord: alleen de credential van de vermelde issuer

Wat de wallet verstuurt

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

Claims die de verifier na validatie ziet

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

De houder had ook een registratiecredential van een niet-vermelde issuer, maar de wallet bood die niet aan. trusted_authorities is een filter voor de wallet, geen garantie: de verifier controleert de issuer bij het valideren van de presentatie zelf nog tegen de vertrouwde lijst.

Een waarde matchen: claims.values

Een claim query kan values bevatten, een lijst met strings, integers of booleans. De wallet geeft de claim alleen terug als het type en de waarde exact overeenkomen met een ervan. Zo kan een verifier een voorwaarde controleren zonder eerst om iets anders te vragen.

Uitgewerkt voorbeeld: alleen bedrijven geregistreerd in Nederland of België

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

Voorbeeldantwoord: een Nederlands bedrijf

Wat de wallet verstuurt

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

Claims die de verifier na validatie ziet

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

De credential van een Duits bedrijf heeft registration_country "DE", dus die voldoet niet aan de query en de wallet heeft daarvoor niets terug te geven. De verifier moet de waarde toch zelf controleren in de gevalideerde claims in plaats van te vertrouwen op de filtering van de wallet.

Waar DCQL nu staat

• DCQL is gedefinieerd binnen de OpenID4VP-specificatie zelf, niet als apart document. Het maakt deel uit van de draft sinds het mechanisme werd geïntroduceerd om een eerdere afhankelijkheid van DIF Presentation Exchange voor OpenID4VP-verzoeken te vervangen.
• Het EUDI Wallet Architecture and Reference Framework schrijft OpenID4VP voor als presentatieprotocol en daarmee DCQL als het querymechanisme dat relying parties en wallets in het ecosysteem geacht worden te ondersteunen.
• Referentie-implementaties van wallets en verifiers in het EUDI Wallet Reference Implementation-programma zijn op DCQL uitgekomen. Nieuwe business wallet-integraties die vandaag op OpenID4VP worden gebouwd, moeten dus uitgaan van DCQL, niet van Presentation Exchange, als queryformaat voor presentatieverzoeken.

Veelgestelde vragen

Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende informatie rechtstreeks de OpenID Foundation en de Europese Commissie.