Digital Credentials API

Strona internetowa wywołuje navigator.credentials.get() z żądaniem cyfrowego poświadczenia, które wskazuje protokół prezentacji i jako ładunek niesie własne żądanie tego protokołu. Przeglądarka przekazuje żądanie systemowi operacyjnemu, który wyświetla natywny wybór portfeli zainstalowanych na urządzeniu, a portfel wybrany przez posiadacza zwraca odpowiedź protokołu przez to samo wywołanie. API jedynie przenosi wymianę: to, o co się prosi, co zostaje ujawnione i jak weryfikuje się odpowiedź, nadal określa protokół w jego wnętrzu. Analogiczne wywołanie navigator.credentials.create() robi to samo przy wydawaniu, więc strona może w ten sam sposób przekazać portfelowi Credential Offer.

Wcześniej prezentacja na urządzeniu, z którego posiadacz już korzystał, oznaczała albo kod QR, którego wyświetlający go telefon nie mógł zeskanować, albo deep link, który musiał zgadywać, jaki portfel jest zainstalowany. Przekazanie żądania przez system operacyjny usuwa oba problemy, bo posiadacz dostaje jeden natywny wybór obejmujący wszystkie portfele na urządzeniu, a strona nigdy nie musi sama wykrywać ani wskazywać portfela. Przeglądarka dodaje też do żądania pochodzenie (origin) wywołującej strony, dzięki czemu portfel może pokazać posiadaczowi, która strona pyta, i odrzucić żądanie skopiowane z innego miejsca. To właśnie czyni ten przepływ odpornym na phishing i ataki typu relay.

API jest celowo neutralne wobec protokołów, a w ekosystemie EUDI Wallet liczą się dwa powiązania: OpenID4VP definiuje własny profil dla tego API, a ISO/IEC 18013-7 Annex C wiąże z nim tę samą wymianę mdoc. EUDI ARF omawia je jako sposób na usprawnienie zdalnej prezentacji, pod warunkiem że przeglądarka przekazuje origin strony ufającej, aby w Wallet Unit dało się ustalić, kto pyta, oraz że przepływ między dwoma urządzeniami zachowuje sprawdzenie ich bliskości. Pobieranie danych z urządzenia według ISO/IEC 18013-5 pozostaje więc kanałem do kontaktu osobistego, a nie czymś, co API przeglądarki zastępuje.

Obsługa nie jest już eksperymentalna. API jest domyślnie włączone w Chrome na Androidzie i na komputerach oraz w Safari w najnowszych wydaniach Apple, natomiast Firefox go nie włączył. Przeglądarki wciąż różnią się tym, jakie protokoły i formaty poświadczeń akceptują, a obsługa na komputerach zwykle polega na sparowaniu z telefonem, na którym jest portfel, a nie na przechowywaniu poświadczeń w przeglądarce. Warto traktować je jako ulepszenie dla przeglądarek i urządzeń, które je obsługują, i zachować kod QR lub przepływ z przekierowaniem dla pozostałych.