DCQL w pigułce: jak weryfikator prosi portfel dokładnie o to, czego potrzebuje
DCQL, czyli Digital Credentials Query Language, to uzgodniony sposób, w jaki organizacja mówi portfelowi, jakich poświadczeń potrzebuje i jakich danych w ich wnętrzu. To on zamienia żądanie w rodzaju "wykaż, że twoja firma jest zarejestrowana w Holandii" w coś, co rozumie każdy zgodny portfel, bez osobnej integracji dla każdego portfela.
Problem, który rozwiązuje DCQL
Portfel firmowy przechowuje poświadczenia wielu rodzajów, wydane przez różne podmioty w różnych krajach i zapisane w różnych formatach technicznych. Organizacja, która musi jedynie potwierdzić numer rejestrowy i nazwę prawną, nie ma przenośnego sposobu, by poprosić dokładnie o to. Kończy się albo na pobraniu całego poświadczenia, ze wszystkim, co w nim jest, albo na budowaniu osobnej integracji dla każdego napotkanego portfela.
DCQL porządkuje stronę pytającą. Jedno standardowe żądanie wskazuje potrzebne poświadczenia i konkretne dane oczekiwane z każdego z nich. Portfel zestawia je z tym, co posiadacz faktycznie ma, pokazuje posiadaczowi, o co jest pytany, i udostępnia wyłącznie to. Weryfikator otrzymuje przewidywalną odpowiedź niezależnie od tego, z jakiego portfela korzysta posiadacz.
1. Weryfikator
Prosi dokładnie o te poświadczenia i dane, których potrzebuje
2. Portfel
Ustala, które z zapisanych poświadczeń pasują do żądania
3. Posiadacz
Widzi, o co jest pytany, i zgadza się na udostępnienie wyłącznie tego
4. Weryfikator
Otrzymuje zatwierdzone dane i nic ponadto
O co może poprosić weryfikator
Żądanie to krótka lista tego, co jest potrzebne. Może wskazywać jedno poświadczenie lub kilka, a dla każdego z nich może wskazywać konkretne oczekiwane dane zamiast całości. Trzy dodatkowe możliwości pokrywają niemal każdy realny przypadek: warianty zapasowe, kombinacje i ograniczenie akceptowanych wystawców.
- Które poświadczenia są potrzebne i które dane w każdym z nich.
- Dopuszczalne warianty zapasowe, w kolejności preferencji, dla posiadaczy, którzy nie mają wszystkiego.
- Kombinacje, dzięki którym żądanie może wymagać jednego poświadczenia i jednego z dwóch innych.
- Ograniczenie do wystawców z oficjalnej listy zaufanych, dzięki czemu poświadczenia od kogokolwiek innego nigdy nie są proponowane.
Prośba o wariant zapasowy
Nie każdy posiadacz ma takie samo poświadczenie. Weryfikator może wskazać, co wolałby otrzymać i co nadal zaakceptuje, w kolejności, a portfel użyje najlepszej opcji, którą posiadacz faktycznie jest w stanie spełnić. Dzięki temu nie trzeba pytać drugi raz ani odsyłać klienta, któremu brakuje tylko szczegółu dobrego do posiadania.
1. Preferowany
Używane, gdy poświadczenie zawiera oba dane
2. Rezerwowy
Używane tylko wtedy, gdy pierwszej opcji nie da się spełnić
Tutaj weryfikator wolałby otrzymać numer rejestrowy razem z nazwą prawną, ale zaakceptuje samą nazwę prawną, gdy poświadczenie posiadacza nie zawiera numeru rejestrowego.
Łączenie poświadczeń w jednym żądaniu
Kontrole przy onboardingu rzadko opierają się na jednym dokumencie. Weryfikator może wymagać jednego poświadczenia i zaakceptować obok niego jedno z dwóch innych, wszystko w jednym żądaniu, więc posiadacz zatwierdza raz, a weryfikator otrzymuje pełną odpowiedź w jednym kroku.
Wymagane
Rejestracja spółki
Jedno z
Rejestracja VAT
Jedno z
Poświadczenie rachunku bankowego
Wpis do rejestru firmy jest wymagany. Poza tym wystarczy rejestracja VAT albo poświadczenie rachunku bankowego, a posiadacz musi mieć tylko jedno z nich.
Akceptowanie wyłącznie zaufanych wystawców
Weryfikator może zawęzić żądanie do poświadczeń, których wystawca figuruje na oficjalnej liście zaufanych. Poświadczenia od kogokolwiek innego nie są nawet proponowane posiadaczowi, więc samodzielnie wystawiona podróbka w ogóle nie dociera do kontroli.
Weryfikator mówi: wyłącznie od wystawców z oficjalnej unijnej listy zaufanych
Poświadczenie rejestracji od wystawcy z listy
Wystawca figuruje na liście zaufanych
✓ Proponowane posiadaczowi
Poświadczenie rejestracji od wystawcy spoza listy
Wystawca nie figuruje na liście zaufanych
✗ Nieproponowane posiadaczowi
To filtr w portfelu, a nie gwarancja sama w sobie. Weryfikator nadal sprawdza wystawcę na liście zaufanych, gdy waliduje to, co otrzymał.
Obecny status DCQL
- DCQL jest częścią samej specyfikacji OpenID4VP, a nie osobnym dokumentem, i zastąpił wcześniejszą zależność od DIF Presentation Exchange.
- EUDI Wallet Architecture and Reference Framework wskazuje OpenID4VP jako protokół prezentacji, a wraz z nim DCQL, więc oczekuje się, że portfele i weryfikatory w ekosystemie będą go obsługiwać.
- Referencyjne portfele i weryfikatory w programie EUDI Wallet skupiły się wokół DCQL, więc integracja z portfelem firmowym rozpoczynana dzisiaj powinna zakładać jego użycie zamiast starszej alternatywy.
Co to oznacza dla ciebie
Weryfikator
Jeden format żądania obsługuje każdy portfel, a ty otrzymujesz tylko te dane, o które poprosiłeś, czyli mniej danych do przechowywania, zabezpieczania i uzasadniania.
Posiadacz
Widzisz dokładnie, o co jesteś pytany, zanim zatwierdzisz, i nic ponad to nie opuszcza twojego portfela.
Wystawca
Wydawane przez ciebie poświadczenia pozostają przydatne do częściowych kontroli, więc jedno poświadczenie może służyć wielu różnym celom.
Pogłębienie techniczne
Ta strona wyjaśnia, co robi ta technologia i kogo dotyczy. Nasza dokumentacja dla programistów opisuje samo wdrożenie: komunikaty, pola i omówione przykłady, których potrzebuje zespół integracyjny.
Przeczytaj dokumentację technicznąPowiązane pojęcia
Najczęściej zadawane pytania
Czym DCQL różni się od DIF Presentation Exchange?
Oba są sposobami opisania przez weryfikatora tego, czego oczekuje od portfela. Presentation Exchange jest starszy i szerszy, zaprojektowany do działania w wielu protokołach. DCQL jest celowo mniejszy i zdefiniowany wewnątrz samego OpenID4VP. Ekosystem EUDI Wallet przyjął DCQL jako standard, więc to na nim należy opierać plany na rynek europejski.
Czy jedno żądanie może dotyczyć więcej niż jednego poświadczenia?
Tak, i to jeden z powodów jego istnienia. Weryfikator może poprosić o wpis do rejestru firmy i o poświadczenie rachunku bankowego w jednym żądaniu albo zaakceptować jedno z dwóch rozwiązań, a posiadacz zatwierdza wszystko w jednym kroku, zamiast być pytany dwa razy.
Co się dzieje, jeśli posiadacz nie ma wszystkiego, o co poproszono?
Weryfikator może wskazać dopuszczalne warianty zapasowe, w kolejności preferencji, a portfel użyje najlepszego, który posiadacz faktycznie jest w stanie spełnić. Dzięki temu weryfikator może poprosić o dokładny numer rejestrowy tam, gdzie istnieje, i poprzestać na nazwie prawnej tam, gdzie go nie ma, bez wysyłania drugiego żądania i bez odsyłania posiadacza.
Czy DCQL jest specyficzny dla EUDI Wallet?
Nie. DCQL jest częścią OpenID4VP i może z niego korzystać każda implementacja tego protokołu. Ekosystem EUDI Wallet jest jego ważnym użytkownikiem: Architecture and Reference Framework wskazuje OpenID4VP wraz z DCQL jako sposób prezentowania poświadczeń, dlatego ma to znaczenie dla każdego, kto buduje rozwiązania na rynek europejski.
Czy pomaga to w minimalizacji danych zgodnie z GDPR?
Czyni minimum wyraźnym. Żądanie określa, które dane są potrzebne, posiadacz widzi tę listę przed zatwierdzeniem, a portfel nie udostępnia niczego ponad nią. Minimalizacja danych przestaje być obietnicą z polityki, a staje się granicą egzekwowaną przez samą wymianę, co jest znacznie łatwiejsze do wykazania.
Źródła
Ta strona ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. Wiążących wskazówek należy szukać bezpośrednio w OpenID Foundation i Komisji Europejskiej.