DCQL erklärt: wie ein Verifier eine Wallet um genau das bittet, was er braucht

Das Problem, das DCQL löst

Einen Fallback anfordern: claim_sets

claim_sets listet Gruppen von Claim-ids in der Reihenfolge der Präferenz. Die Wallet liefert die erste Gruppe, die sie mit dem, was der Inhaber tatsächlich besitzt, vollständig erfüllen kann. Der Verifier muss also keine zwei getrennten Anfragen für den genauen Fall und den Fallback senden.

{
  "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 bevorzugt der Verifier eine Registernummer plus Firmenname, akzeptiert aber auch nur den Firmennamen, wenn das Credential des Inhabers keinen Claim mit Registernummer enthält.

{
  "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 kombinieren: credential_sets

credential_sets arbeitet eine Ebene über claim_sets. Jeder Eintrag listet options, wobei jede Option eine Gruppe von Credential-Query-ids ist. Die Wallet muss eine Option jedes erforderlichen Eintrags erfüllen. So erhält ein Verifier UND- und ODER-Logik über mehrere Credentials in einer einzigen Anfrage.

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

Beispielantwort: Registrierung plus Bankkonto

Was die Wallet sendet

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

Claims, die der Verifier nach der Validierung sieht

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

Der Inhaber hat kein Credential zur USt-Registrierung, daher hat die Wallet die zweite Option des zweiten Sets gewählt. Nicht verwendete Query-ids, hier vat_registration, fehlen in vp_token einfach.

Nur vertrauenswürdige Aussteller: trusted_authorities

trusted_authorities schränkt eine Credential Query auf Credentials ein, deren Aussteller von einer Autorität gestützt wird, der der Verifier vertraut. Jeder Eintrag hat einen type und eine Liste von values: aki für einen Authority Key Identifier, etsi_tl für eine ETSI Trusted List oder openid_federation für einen Trust Anchor einer Föderation. Die Wallet bietet nur passende Credentials an.

Praxisbeispiel: eine Registrierung von einem gelisteten Aussteller

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

Beispielantwort: nur das Credential des gelisteten Ausstellers

Was die Wallet sendet

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

Claims, die der Verifier nach der Validierung sieht

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

Der Inhaber hatte auch ein Registrierungs-Credential eines nicht gelisteten Ausstellers, doch die Wallet hat es nicht angeboten. trusted_authorities ist ein Filter für die Wallet, keine Garantie: Der Verifier prüft den Aussteller bei der Validierung der Präsentation trotzdem selbst gegen die Vertrauensliste.

Einen Wert abgleichen: claims.values

Eine Claim Query kann values enthalten, eine Liste von Strings, Integern oder Booleans. Die Wallet liefert den Claim nur, wenn Typ und Wert exakt einem davon entsprechen. So kann ein Verifier eine Bedingung prüfen, ohne vorher etwas anderes anzufordern.

Praxisbeispiel: nur in den Niederlanden oder Belgien registrierte Unternehmen

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

Beispielantwort: ein niederländisches Unternehmen

Was die Wallet sendet

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

Claims, die der Verifier nach der Validierung sieht

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

Das Credential eines deutschen Unternehmens hat registration_country "DE", erfüllt die Abfrage also nicht, und die Wallet hat dafür nichts zurückzugeben. Der Verifier sollte den Wert dennoch in den validierten Claims prüfen, statt sich auf die Filterung der Wallet zu verlassen.

Wo DCQL heute steht

• DCQL ist innerhalb der OpenID4VP-Spezifikation selbst definiert, nicht als separates Dokument, und ist Teil des Entwurfs, seit der Mechanismus eingeführt wurde, um eine frühere Abhängigkeit von DIF Presentation Exchange für OpenID4VP-Anfragen abzulösen.
• Das EUDI Wallet Architecture and Reference Framework legt OpenID4VP als Präsentationsprotokoll fest und damit DCQL als den Abfragemechanismus, den Relying Parties und Wallets im Ökosystem unterstützen sollen.
• Die Referenzimplementierungen für Wallets und Verifier im EUDI Wallet Reference Implementation-Programm setzen inzwischen einheitlich auf DCQL. Neue Business-Wallet-Integrationen, die heute auf OpenID4VP aufbauen, sollten daher DCQL und nicht Presentation Exchange als Abfrageformat für Präsentationsanfragen voraussetzen.

Häufig gestellte Fragen

Diese Seite dient nur der Information und stellt keine Rechtsberatung dar. Verbindliche Auskünfte erhalten Sie direkt bei der OpenID Foundation und der Europäischen Kommission.