DCQL erklärt: wie ein Verifier eine Wallet um genau das bittet, was er braucht
DCQL, die Digital Credentials Query Language, ist der vereinbarte Weg, auf dem eine Organisation einer Wallet mitteilt, welche Nachweise sie braucht und welche Angaben darin. Sie macht aus einer Anfrage wie "belegen Sie, dass Ihr Unternehmen in den Niederlanden eingetragen ist" etwas, das jede konforme Wallet versteht, ohne eine eigene Integration je Wallet.
Das Problem, das DCQL löst
Eine Business Wallet enthält Nachweise vieler Arten, ausgestellt von unterschiedlichen Stellen in unterschiedlichen Ländern und gespeichert in unterschiedlichen technischen Formaten. Eine Organisation, die nur eine Registernummer und einen Firmennamen bestätigen muss, hat keinen übertragbaren Weg, genau danach zu fragen. Sie nimmt am Ende entweder den ganzen Nachweis mit allem, was darin steht, oder sie baut eine eigene Integration für jede Wallet, der sie begegnet.
DCQL löst die Frageseite. Eine Standardanfrage benennt die gewünschten Nachweise und die konkreten Angaben, die aus jedem davon gebraucht werden. Die Wallet gleicht das mit dem ab, was der Inhaber tatsächlich hat, zeigt dem Inhaber, was gefragt wird, und gibt nur das frei. Der Prüfer erhält eine vorhersehbare Antwort, unabhängig davon, welche Wallet der Inhaber nutzt.
1. Verifier
Fragt genau nach den Nachweisen und Angaben, die gebraucht werden
2. Wallet
Ermittelt, welche der gespeicherten Nachweise zur Anfrage passen
3. Inhaber
Sieht, was gefragt wird, und stimmt zu, nur das freizugeben
4. Verifier
Erhält die freigegebenen Angaben, und nichts weiter
Wonach ein Prüfer fragen kann
Eine Anfrage ist eine kurze Liste dessen, was gebraucht wird. Sie kann einen Nachweis oder mehrere benennen, und für jeden kann sie die konkreten gewünschten Angaben benennen statt des Ganzen. Drei Optionen darüber hinaus decken fast jeden realen Fall ab: Rückfalloptionen, Kombinationen und eine Beschränkung darauf, welche Aussteller akzeptabel sind.
- Welche Nachweise gebraucht werden und welche Angaben in jedem einzelnen.
- Akzeptable Rückfalloptionen, in der Reihenfolge der Präferenz, für Inhaber, die nicht alles haben.
- Kombinationen, sodass eine Anfrage einen Nachweis verlangen und daneben einen von zwei weiteren akzeptieren kann.
- Eine Beschränkung auf Aussteller auf einer offiziellen trusted list, sodass Nachweise von anderen nie angeboten werden.
Nach einer Rückfalloption fragen
Nicht jeder Inhaber führt denselben Nachweis mit sich. Ein Prüfer kann benennen, was er bevorzugt und was er zusätzlich noch akzeptiert, in einer Reihenfolge, und die Wallet nutzt die beste Option, die der Inhaber tatsächlich erfüllen kann. Das erspart eine zweite Runde und verhindert, dass ein Kunde abgewiesen wird, dem nur das angenehmste Detail fehlt.
1. Bevorzugt
Wird genutzt, wenn der Nachweis beides enthält
2. Fallback
Wird nur genutzt, wenn die erste Option nicht erfüllbar ist
Hier möchte der Prüfer am liebsten eine Registernummer zusammen mit dem Firmennamen, akzeptiert aber den Firmennamen allein, wenn der Nachweis des Inhabers keine Registernummer enthält.
Nachweise in einer Anfrage kombinieren
Onboarding-Prüfungen stützen sich selten auf ein einziges Dokument. Ein Prüfer kann einen Nachweis verlangen und daneben einen von zwei weiteren akzeptieren, alles in einer Anfrage, sodass der Inhaber einmal zustimmt und der Prüfer in einem Schritt eine vollständige Antwort erhält.
Erforderlich
Handelsregistereintrag
Eines von
USt-Registrierung
Eines von
Bankkontonachweis
Ein Handelsregistereintrag ist Pflicht. Darüber hinaus genügt eine Umsatzsteuerregistrierung oder ein Nachweis über ein Bankkonto, und der Inhaber braucht nur eines davon.
Nur vertrauenswürdige Aussteller akzeptieren
Ein Prüfer kann eine Anfrage auf Nachweise verengen, deren Aussteller auf einer offiziellen trusted list steht. Nachweise von anderen werden dem Inhaber gar nicht erst angeboten, sodass eine selbst ausgestellte Nachahmung die Prüfung überhaupt nicht erreicht.
Der Prüfer sagt: nur von Ausstellern auf einer offiziellen EU trusted list
Registrierungs-Credential eines gelisteten Ausstellers
Der Aussteller steht auf der trusted list
✓ Dem Inhaber angeboten
Registrierungs-Credential eines nicht gelisteten Ausstellers
Der Aussteller steht nicht auf der trusted list
✗ Dem Inhaber nicht angeboten
Das ist ein Filter in der Wallet, keine Garantie für sich allein. Der Prüfer gleicht den Aussteller weiterhin mit der trusted list ab, wenn er prüft, was er erhalten hat.
Wo DCQL heute steht
- DCQL ist Teil der OpenID4VP-Spezifikation selbst und kein eigenes Dokument, und es hat eine frühere Abhängigkeit von DIF Presentation Exchange abgelöst.
- Das EUDI Wallet Architecture and Reference Framework nennt OpenID4VP als Vorlageprotokoll und DCQL dazu, also wird von Wallets und Prüfern im Ökosystem erwartet, dass sie es unterstützen.
- Die Referenz-Wallets und Prüfer im EUDI Wallet-Programm haben sich auf DCQL verständigt, also sollte eine heute begonnene Business Wallet-Integration davon ausgehen und nicht von der älteren Alternative.
Was das für Sie bedeutet
Verifier
Ein Anfrageformat deckt jede Wallet ab, und Sie erhalten nur die Angaben, nach denen Sie gefragt haben, also weniger Daten zum Speichern, Schützen und Rechtfertigen.
Inhaber
Sie sehen genau, was gefragt wird, bevor Sie zustimmen, und nichts darüber hinaus verlässt Ihre Wallet.
Aussteller
Nachweise, die Sie ausstellen, bleiben für Teilprüfungen nutzbar, sodass ein Nachweis viele verschiedene Zwecke erfüllen kann.
Technische Vertiefung
Diese Seite erklärt, was die Technologie leistet und wen sie betrifft. Unsere Entwicklerdokumentation behandelt die Umsetzung selbst: die Nachrichten, die Felder und die ausgearbeiteten Beispiele, die ein Integrationsteam braucht.
Technische Dokumentation lesenVerwandte Begriffe
Häufig gestellte Fragen
Worin unterscheidet sich DCQL von DIF Presentation Exchange?
Beides sind Wege, mit denen ein Prüfer beschreibt, was er von einer Wallet möchte. Presentation Exchange ist das ältere und breitere der beiden und wurde für mehrere Protokolle entworfen. DCQL ist bewusst kleiner und ist in OpenID4VP selbst definiert. Das EUDI Wallet-Ökosystem hat sich auf DCQL festgelegt, also ist das die Wahl für den europäischen Markt.
Kann eine Anfrage nach mehr als einem Nachweis fragen?
Ja, und das ist einer der Gründe, warum es das gibt. Ein Prüfer kann in einer einzigen Anfrage einen Handelsregistereintrag und einen Nachweis über ein Bankkonto verlangen oder eine von zwei Alternativen akzeptieren, und der Inhaber stimmt allem in einem Schritt zu, statt zweimal gefragt zu werden.
Was passiert, wenn der Inhaber nicht alles hat, wonach gefragt wurde?
Der Prüfer kann akzeptable Rückfalloptionen benennen, in der Reihenfolge seiner Präferenz, und die Wallet nutzt die beste, die der Inhaber tatsächlich erfüllen kann. So kann ein Prüfer nach einer genauen Registernummer fragen, wo es sie gibt, und sich mit dem Firmennamen begnügen, wo es sie nicht gibt, ohne eine zweite Anfrage zu senden oder den Inhaber abzuweisen.
Ist DCQL spezifisch für die EUDI Wallet?
Nein. DCQL ist Teil von OpenID4VP, und jede Implementierung dieses Protokolls kann es nutzen. Das EUDI Wallet-Ökosystem ist ein prominenter Anwender: Das Architecture and Reference Framework nennt OpenID4VP mit DCQL als den Weg, auf dem Nachweise vorgelegt werden, und deshalb ist es für alle relevant, die für den europäischen Markt bauen.
Hilft das bei der Datenminimierung nach der GDPR?
Es macht das Minimum ausdrücklich sichtbar. Die Anfrage nennt, welche Angaben nötig sind, der Inhaber sieht diese Liste vor seiner Zustimmung, und die Wallet gibt nichts darüber hinaus frei. Damit wird Datenminimierung aus einem Versprechen in einer Richtlinie zu einer Grenze, die der Austausch selbst durchsetzt, und das lässt sich sehr viel leichter nachweisen.
Quellen
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.