Data publikacji: 3 października 2025 r.
Z przyjemnością informujemy, że interfejs Digital Credentials API jest teraz domyślnie włączony w Chrome 141. Dodatkowo iOS 26 dodaje obsługę interfejsu Digital Credentials API w Chrome i innych przeglądarkach. Ten interfejs API zapewnia nowy poziom bezpieczeństwa i prywatności w zakresie weryfikacji tożsamości w internecie. Umożliwia on witrynom standardowe wysyłanie do użytkowników próśb o informacje, które można zweryfikować, i otrzymywanie takich informacji.
Po pomyślnym zakończeniu testu Origin Trial interfejs Digital Credentials API obsługuje teraz zarówno prezentowanie danych logowania na tym samym urządzeniu z Androidem, jak i prezentowanie ich na różnych urządzeniach w Chrome na komputerze.
Tło
Weryfikacja tożsamości online była do tej pory złożonym procesem, który często wymagał od użytkowników przesyłania skanów dokumentów tożsamości. Często oznacza to udostępnianie większej ilości danych niż jest to konieczne, co budzi poważne obawy użytkowników dotyczące prywatności. Dla deweloperów wiąże się to też z ryzykiem, ponieważ muszą oni zadbać o to, aby ich rozwiązanie było w stanie przetwarzać i przechowywać często niejednolite dane wrażliwe w bezpieczny sposób, z zachowaniem prywatności.
Jednocześnie przepisy takie jak eIDAS 2.0 nakładają na rządy obowiązek udostępniania obywatelom środków identyfikacji cyfrowej. Te cyfrowe portfele tożsamości muszą umożliwiać przechowywanie różnych dokumentów, w tym potwierdzenia tożsamości i wieku. Dostawcy usług online mogą prosić o te dane logowania, aby potwierdzić tożsamość użytkownika.
Społeczność zajmująca się standardami internetowymi w W3C, dostrzegając potencjał cyfrowych danych logowania w zakresie zaspokajania zarówno potrzeb użytkowników w zakresie prywatności, jak i potrzeb deweloperów w zakresie weryfikowania danych użytkowników, opracowała rozwiązanie: Digital Credentials API. Interfejs Digital Credentials API ma rozwiązać ten problem przez wprowadzenie wbudowanego interfejsu do weryfikacji informacji o użytkowniku, co poprawia bezpieczeństwo, prywatność i wygodę użytkownika w porównaniu z alternatywnymi rozwiązaniami. Dzięki temu interfejsowi API użytkownicy nie muszą już przesyłać poufnych dokumentów, takich jak skany dokumentów tożsamości, do wielu witryn. Zamiast tego witryny mogą budować zaufanie użytkowników, prosząc tylko o konkretne, podpisane kryptograficznie dane od zaufanych wystawców.
Funkcje główne
Interfejs Digital Credentials API opiera się na 3 podstawowych zasadach: prywatności, obsłudze różnych platform i standaryzacji.
Prywatność
Interfejs Digital Credentials API zwiększa prywatność i bezpieczeństwo w internecie. Umożliwia użytkownikom przedstawianie cyfrowego dokumentu tożsamości z portfela mobilnego w witrynach, aby weryfikować określone fakty bez ujawniania podstawowych danych wrażliwych. Na przykład interfejs API może potwierdzić, że użytkownik ma ukończone 18 lat, bez ujawniania jego pełnej daty urodzenia. Zasada „selektywnego ujawniania” zapewnia, że witryny otrzymują tylko niezbędne minimum informacji.
Interfejs Digital Credentials API jest też zgodny z protokołami dowodów z zerową wiedzą (ZKP), takimi jak Longfellow ZK od Google, który zapewnia prywatność użytkownika, zwracając kryptograficzny dowód, że określone stwierdzenie tożsamości jest prawdziwe, bez ujawniania żadnych innych informacji.
Działanie na różnych platformach
Interfejs Digital Credentials API ma obsługiwać różne platformy, aby użytkownicy mogli wygodnie prezentować zweryfikowane informacje na różnych urządzeniach.
Na Androidzie: udostępnia wbudowany interfejs użytkownika, który umożliwia wybieranie danych logowania z zainstalowanej aplikacji portfela.
Na komputerze: użytkownicy mogą prezentować dokumenty z portfela mobilnego w witrynie w przeglądarce na komputerze. Po zeskanowaniu kodu QR system nawiązuje bezpieczne, w pełni zaszyfrowane i odporne na phishing połączenie między komputerem a urządzeniem mobilnym. To połączenie wykorzystuje protokół CTAP do weryfikacji bliskości użytkownika za pomocą BLE, co zapewnia, że jest on fizycznie obecny i ma kontrolę nad obydwoma urządzeniami.
Standaryzacja
Interoperacyjność jest kluczowa. W Chrome interfejs Digital Credentials API jest niezależny od platformy protokołu i jest zgodny z różnymi protokołami prezentacji, np. OpenID4VP i załącznikiem C normy ISO 18013-7. Firma Apple wprowadziła też obsługę interfejsu Digital Credentials API w Safari 26.0.
Interfejs Digital Credentials API korzysta z wbudowanej obsługi zarządzania danymi logowania w Androidzie i rozwijającego się ekosystemu kompatybilnych portfeli. Portfel Google jest jednym z pierwszych, którzy wprowadzili tę funkcję. Wkrótce będzie ona dostępna w Portfelu Samsung i 1Password.
Co nowego od czasu testowania interfejsu Origin Trial?
Uczestnicy wcześniejszej wersji próbnej origin zauważą, że interfejs Digital Credentials API został przeniesiony z navigator.identity.get() do navigator.credentials.get(), co jest zgodne z szerszymi działaniami na rzecz ujednolicenia tożsamości za pomocą interfejsu Credential Management API.
Dodatkowo nazwa parametru providers została zmieniona na requests, a nazwa parametru request została zmieniona na data.
Implementacja
Integracja interfejsu Digital Credentials API obejmuje 2 główne etapy: wykrywanie funkcji i wysyłanie prośby o dane logowania. Deweloperzy powinni też wdrożyć niestandardową logikę, aby określić, czy aplikacja może używać danych logowania.
Wykrywanie cech
Zanim wyświetlisz przycisk „Zweryfikuj za pomocą dokumentu cyfrowego”, sprawdź, czy interfejs Digital Credentials API jest dostępny w przeglądarce użytkownika.
if (typeof DigitalCredential !== "undefined") {
// Digital Credentials API is supported
} else {
// Digital Credentials API is not supported
}
Prośba o dane logowania
Żądanie danych logowania obejmuje wywołanie funkcji navigator.credentials.get() z parametrem digital. W typie danych logowania cyfrowego dodaj tablicę requests, która zawiera DigitalCredentialGetRequest z tymi podstawowymi parametrami:
protocol: określ protokół wymiany za pomocą ciągu tekstowego. Na przykład"openid4vp"lub"org-iso-mdoc". Sprawdź, czy protokół jest obsługiwany przez przeglądarkę:if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) { // Create a request with this protocol } else { // Protocol is not supported }data: obiekt z parametrami, które aplikacje portfela cyfrowego akceptują w przypadku określonego protokołu. Parametry"openid4vp"są zdefiniowane w OpenID for Verifiable Presentation (OID4VP) w specyfikacji interfejsu W3C Digital Credentials API.try { const digitalCredential = await navigator.credentials.get({ digital: { requests: [{ protocol: "openid4vp-v1-unsigned", data: { response_type: "vp_token", nonce: "[some-nonce]", client_metadata: {...}, dcql_query: {...} } }] } }); // Decrypt payload respons and verify credentials on the backend const response = await fetch("/verify", { method: "POST", body: JSON.stringify(digitalCredential.data), headers: { 'Content-Type': 'application/json' } }); } catch (e) { // Handle errors, such as the user canceling the request console.error(e); }
Aby na przykład poprosić o nazwisko, imię i wartość logiczną wskazującą, czy użytkownik ma ukończone 21 lat, możesz podać ten ładunek:
{
protocol: 'openid4vp-v1-unsigned',
data: {
response_type: 'vp_token',
nonce: '[some-nonce]',
// Contains the Verifier metadata values, including supported credential formats and response encryption public key
client_metadata: {
// Supported credential formats. Refer to the documentation for specific values
vp_formats_supported: {...},
// Public key(s). Refer to the documentation for more detail.
jwks: {...}
},
dcql_query: {
// A wallet will try to find credentials it holds that match these definitions.
credentials: [
{
// A locally unique identifier for this credential definition within the query.
id: "cred_vc",
format: "dc+sd-jwt",
meta: {
// 'vct_values' specifies the Verifiable Credential allowed type.
// In this case, it's a European Digital Identity (EUDI) Personal Identification Data (PID) credential.
vct_values: [
"urn:eudi:pid:1"
]
},
// 'claims' is an array of specific data that's being requested.
claims: [
{
// The path ["age_equal_or_over", "18"] corresponds to accessing `credential.age_equal_or_over['18']`.
path: [
"age_equal_or_over",
"18"
]
}
]
}
]
}
}
}
W tym przykładzie element client_metadata musi zawierać listę obsługiwanych formatów. Aby sprawdzić, których wartości można używać, zapoznaj się ze specyfikacją. Opcjonalnajwks wartość ustawiona w client_metadata musi zawierać klucze publiczne używane do szyfrowania odpowiedzi. Więcej przykładów znajdziesz w kodzie demonstracyjnym.
Oto przykład zaszyfrowanego ładunku odpowiedzi obiektu DigitalCredential:
{
// This is an example for a response using an OpenID4VP protocol.
// The format of the 'data' object will differ for other protocols.
"protocol": "openid4vp-v1-unsigned",
"data": {
// To decrypt this JWE payload, use the private key.
// The decrypted payload will be a JSON object containing the
// Verifiable Presentation in the 'vp_token' claim.
"response": "[jwe-token]"
}
}
W tym przykładzie system wysyła żądanie danych logowania z protokołem openid4vp-v1-unsigned, a odpowiedź zawiera response we właściwości data.
Dokładny sposób analizowania odpowiedzi zależy od protokołu. Zwykle musisz:
- Odszyfruj ładunek odpowiedzi. Metoda odszyfrowywania zależy od użytego protokołu. Dowiedz się, jak odszyfrować ładunek w przypadku
openid4vp(przy użyciu JWE) iorg-iso-mdoc(przy użyciu hybrydowego szyfrowania kluczem publicznym). - Weryfikacja podpisów i wydawcy Więcej informacji znajdziesz w dokumentacji dotyczącej akceptacji online dokumentów cyfrowych.
Przykładowe fragmenty kodu dla różnych protokołów znajdziesz w kodzie wersji demonstracyjnej lub w wersji hostowanej na żywo.
Weryfikacja zaufania do wydawcy
Podpis kryptograficzny cyfrowych dokumentów potwierdza ich autentyczność. Deweloperzy muszą jednak sprawdzić, czy wydawca jest odpowiedni i godny zaufania w konkretnym przypadku użycia. Na przykład, aby przyznać zniżkę dla studentów, witryna e-commerce wymagałaby poświadczenia wydanego przez akredytowaną uczelnię i odrzucałaby poświadczenia podpisane przez inne podmioty. Powszechnym sposobem weryfikacji zaufania do wystawcy jest prowadzenie listy zatwierdzonych wystawców i odrzucanie wszystkich, którzy nie pasują do tej listy.
Rozpocznij
Chcesz zacząć tworzyć swoje rozwiązanie? Oto co musisz wiedzieć.
- Dostępność: Chrome w wersji 141 lub nowszej domyślnie włącza interfejs Digital Credentials API na różnych platformach.
- Wymagania wstępne: użytkownicy muszą mieć zgodne urządzenie, np. urządzenie z Androidem z Usługami Google Play w wersji 24.0 lub nowszej albo urządzenie z iOS w wersji 26 lub nowszej. Na urządzeniu musi być zainstalowana aplikacja cyfrowego portfela obsługująca Digital Credentials API, np. Portfel Google lub wersja demonstracyjna portfela.
- Wypróbuj wersję demonstracyjną: najlepszym sposobem na poznanie wygody użytkownika i przetestowanie implementacji jest wypróbowanie wersji demonstracyjnej na stronie https://verifier.multipaz.org w Chrome w wersji 141 lub nowszej.
Zasoby
Więcej informacji znajdziesz w tych materiałach:
- Przewodnik dla deweloperów: interfejs Digital Credentials API
- Specyfikacja: W3C Digital Credentials
- Obsługa Androida: Obsługa cyfrowych dokumentów tożsamości na Androidzie
Prześlij opinię
Interfejs Digital Credentials API jest już dostępny, więc chcielibyśmy poznać Twoją opinię na temat korzystania z niego. Zgłoś problem, aby podzielić się opinią lub zgłosić błędy.