Przejdź do głównej treści

Digital Credentials API wyjaśnione

Digital Credentials API to uzgodniony mechanizm, który pozwala stronie internetowej poprosić o poświadczenie bezpośrednio z twojego portfela, przez przeglądarkę i system operacyjny urządzenia, które już trzymasz w ręku. Na telefonie z twoim portfelem nie pojawia się żaden kod QR i nie jesteś odsyłany do innej aplikacji, a potem z powrotem. Dotykasz raz, telefon pokazuje ci, kto pyta, a decyzja należy do ciebie. Na laptopie przeglądarka wyświetla własny kod QR, aby dotrzeć do twojego telefonu.

Objazd, który znika

Do tej pory strona, która chciała czegoś od portfela, musiała jakoś dostarczyć do niego żądanie. W praktyce oznaczało to umieszczenie kodu QR na stronie albo otwarcie linku, który przekazuje odwiedzającego do aplikacji i, miejmy nadzieję, sprowadza go z powrotem. Oba sposoby działają i oba gubią ludzi na każdym kroku.

Najgorzej jest na telefonie, gdzie kod QR znajduje się na tym samym ekranie co aparat, który miałby go zeskanować. Digital Credentials API zamyka tę lukę, bo żądanie staje się czymś, co przeglądarka i system operacyjny mogą przenieść same, skoro już wiedzą, jakie portfele są na urządzeniu.

To samo urządzenie

Odwiedzający korzysta z telefonu, na którym jest portfel. Właśnie tu Digital Credentials API całkowicie eliminuje kod QR i przełączanie się między aplikacjami.

Na dwóch urządzeniach

Odwiedzający jest na laptopie, a portfel na telefonie, więc nadal potrzebne jest coś, co je połączy. Różnica polega na tym, że przeglądarka sama może wyświetlić ten kod i nim zarządzać.

Jak to wygląda w praktyce

Z perspektywy odwiedzającego to jedno dotknięcie na stronie, na której już był. Pod spodem przeglądarka przekazuje żądanie systemowi operacyjnemu, system operacyjny znajduje portfele, które mogą na nie odpowiedzieć, a portfel pokazuje żądanie do zatwierdzenia, zanim cokolwiek zostanie udostępnione.

1. Strona internetowa

Prosi przeglądarkę o poświadczenie, zamiast wyświetlać kod QR lub otwierać aplikację

2. Przeglądarka i system operacyjny

Ustalają, które portfele na urządzeniu zawierają coś pasującego, i proponują tylko je

3. Posiadacz

Widzi, kto pyta i o co, wybiera portfel, a następnie zatwierdza lub odmawia

4. Znowu strona internetowa

Otrzymuje zatwierdzoną odpowiedź na tej samej stronie, której odwiedzający nigdy nie opuścił

Jedno dotknięcie, jedna strona. Nic nie trafia do strony, dopóki posiadacz tego nie zatwierdzi.

Dlaczego udział przeglądarki ma znaczenie

Kod QR to kartka papieru albo obraz na ekranie i nie powie ci, kto go tam umieścił. Na tym opiera się cały phishing przez kody QR: atakujący podmienia kod, portfel się otwiera, a żądanie wygląda zupełnie normalnie, bo nic w procesie nie wie, skąd naprawdę pochodzi.

Gdy żądanie przechodzi przez przeglądarkę, to ona informuje portfel, która strona pyta, i nie da się jej nakłonić do kłamstwa. Portfel może pokazać posiadaczowi prawdziwą stronę, a odpowiedź może zostać powiązana z tą stroną, więc kopia przechwycona gdzie indziej jest dla nikogo bezużyteczna. To realne zmniejszenie narażenia na oszustwa, a nie tylko płynniejszy ekran.

Jak to się ma do OpenID4VP i EUDI Wallet

Łatwo uznać to za kolejny standard, między którymi trzeba wybierać. Tak nie jest. OpenID4VP pozostaje językiem, którym strona ufająca mówi, czego potrzebuje, i odczytuje otrzymaną odpowiedź, a Digital Credentials API to po prostu lepsza droga dla tej rozmowy, zwłaszcza gdy wszystko dzieje się na jednym urządzeniu.

To samo dotyczy samego poświadczenia. Atestacja EUDI Wallet lub mdoc dociera dokładnie w tym samym formacie, w jakim dotarłaby przez zeskanowany kod, więc kontrole, które weryfikator już wykonuje, pozostają bez zmian. Zespół zyskuje możliwość ominięcia objazdu bez przebudowywania czegokolwiek za nim.

Obsługa pojawia się przeglądarka po przeglądarce i platforma po platformie, a nie wszędzie naraz, dlatego strony ufające wdrażają ją obok ścieżki ze skanowaniem, a nie zamiast niej. Praktyczne podejście to używać API tam, gdzie urządzenie je oferuje, wracać do kodu tam, gdzie go brak, i pozwolić, by rozwiązanie zapasowe zanikało wraz ze wzrostem zasięgu.

Co to oznacza dla ciebie

Strona ufająca

Mniej osób porzuca proces, bo zniknęły kroki, na których wcześniej odpadały, a przeglądarka mówi portfelowi, kim naprawdę jesteś, co zamyka jedną z dróg phishingu.

Posiadacz portfela

Jedno dotknięcie na stronie, na której już jesteś, prawdziwa nazwa tego, kto pyta, i żadnej możliwości, by strona dowiedziała się, jakie masz portfele, chyba że się zgodzisz.

Dostawca portfela

System operacyjny proponuje twój portfel za każdym razem, gdy zawiera on coś pasującego, więc to, czy zostaniesz znaleziony, nie zależy już od tego, czy strona ufająca zdecyduje się umieścić link do ciebie.

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

Czy to oznacza koniec kodów QR?

Nie, zawęża ich zastosowanie i zmienia to, kto je generuje. Przeniesienie żądania z laptopa na telefon nadal wymaga czegoś, co połączy oba urządzenia, a API obsługuje także ten przypadek: kod wyświetla przeglądarka, zamiast każdej strony budującej własny. Całkowicie znika kod na telefonie, który już zawiera portfel, bo tam zawsze był jedynie obejściem.

Czy strona internetowa widzi, jakie portfele mam zainstalowane?

Nie. Strona opisuje, o co prosi, a dopasowanie wykonuje system operacyjny na urządzeniu. Strona nigdy nie dowiaduje się, jakie portfele są zainstalowane ani które z nich zawierały pasujące poświadczenie. Jeśli odmówisz, dowie się tylko, że nic nie wróciło, co z jej perspektywy wygląda dokładnie tak samo, jak brak pasującego poświadczenia.

Czy to zastępuje OpenID4VP?

Nie, oba działają razem. OpenID4VP to język, w którym zapisane są żądanie i odpowiedź, i to się tutaj nie zmienia. Digital Credentials API to droga dostarczenia na urządzeniu, która zastępuje kod QR lub niestandardowy link. Strona ufająca, która już obsługuje OpenID4VP, zachowuje dotychczasową logikę żądań i weryfikacji.

Co właściwie musi zbudować strona ufająca?

Mniej, niż spodziewa się większość zespołów, bo zmienia się tylko front-end. Żądanie generowane przez backend i kontrole wykonywane na odpowiedzi pozostają takie same. Dochodzi wywołanie przeglądarki oraz, dopóki obsługa nie jest powszechna, rozwiązanie zapasowe z kodem QR dla odwiedzających, których przeglądarka lub urządzenie nie obsługuje jeszcze API.

Źródła

  1. W3C Digital Credentials API
  2. OpenID for Verifiable Presentations (OpenID4VP)

Ta strona ma charakter informacyjny i nie stanowi porady prawnej. Digital Credentials API wciąż się zmienia, dlatego wiążące brzmienie sprawdź bezpośrednio w specyfikacji W3C.

Porozmawiaj z nami o integracji z EUDI Wallet