Przegląd

Interfejs Digital Credentials Provisioning API jest podzielony na 3 główne modele zasobów:

Zasób	Opis
Urządzenie	Unikalna instancja urządzenia fizycznego i klucza tożsamości.
Korekta	Proces potwierdzania tożsamości użytkownika przed wydaniem danych logowania.
Dane logowania	DC.

Jako wydawca odpowiadasz za tworzenie tych zasobów i zarządzanie nimi przez cały cykl życia karty cyfrowej.

Założenia

Głównym założeniem tego interfejsu API jest używanie przez urządzenie interfejsu Android Identity Credential API do przechowywania dokumentów tożsamości zdefiniowanych w ISO/IEC 18013-5.

Uwaga: każda metoda, która odwołuje się do MobileDriversLicense, jest specyficzna dla mDL. Inne metody są niezależne od typu dokumentu.

Modele zasobów

Urządzenie

W modelu interfejsu Digital Credentials Provisioning API urządzenie nie jest po prostu urządzeniem z Androidem, na którym użytkownik zarządza dokumentami cyfrowymi za pomocą aplikacji Portfel Google. Jest ono reprezentowane jako połączenie następujących elementów:

• urządzenie fizyczne z Androidem,
• Para kluczy publicznego i prywatnego (zwana „kluczem tożsamości”).
  • Klucz publiczny jest używany przez wystawcę do weryfikowania tożsamości urządzenia.
  • Klucz prywatny jest przechowywany w bezpiecznej pamięci urządzenia.

Podczas wywoływania interfejsu API kombinacja urządzenia i danych logowania jest identyfikowana przez identyfikator referencyjny urządzenia (właściwość deviceReferenceId).

Uwaga: referencyjny identyfikator urządzenia nie jest taki sam jak identyfikator urządzenia ani ANDROID_ID. Dwa różne dokumenty tożsamości na tym samym urządzeniu fizycznym będą miały różne klucze tożsamości i identyfikatory referencyjne urządzenia.

Gdy urządzenie po raz pierwszy komunikuje się z wydawcą, otrzymuje unikalny nonce (aby zapobiec atakom typu replay i zapewnić aktualność). Wartość jednorazowa jest podpisana kluczem tożsamości urządzenia i osadzona w certyfikacie zawierającym klucz tożsamości. Od teraz certyfikat może być używany do weryfikacji urządzenia u wystawcy.

Więcej informacji o certyfikacie znajdziesz w dokumentacji dotyczącej Androida IdentityCredential.

Jeśli ten zasób zostanie zamodelowany jako tabela bazy danych, będzie wyglądać podobnie do tego: Właściwość identityKey to wartość klucza publicznego.

Korekta

Weryfikacja to połączenie tych elementów:

• Dowody dostarczone przez użytkownika w celu potwierdzenia tożsamości
• Decyzja wydawcy podjęta na podstawie dostarczonych dowodów.

Weryfikacja tożsamości zależy od rodzaju dokumentu, o który prosi użytkownik. Podczas tworzenia dokumentu tożsamości użytkownik przesyła zdjęcia fizycznego dokumentu tożsamości i film z jego profilem. Film jest używany przez Google do obliczania prawdopodobieństwa, że przedstawia prawdziwą osobę. Wynik przekazywany przez Google do wydawców jest nazywany „wynikiem weryfikacji”. W miarę dodawania nowych typów dokumentów tożsamości będziemy wprowadzać dodatkowe metody weryfikacji.

Możliwe stany weryfikacji są wymienione w tabeli poniżej.

Stan	Opis	Stan końcowy
Oczekuje	Wydawca nie podjął jeszcze decyzji.	Nie
Zaakceptowano	Wydawca uznał dowody za wystarczające.	Nie
Odrzucono	Wydawca uznał, że dowody nie są wystarczające.	Tak*
Z utrudnieniami	Wystawca potrzebuje więcej informacji, aby podjąć decyzję.	Nie
Anulowano	Użytkownik anulował korektę.	Tak
Unieważniono	Wystawca unieważnił weryfikację.	Tak*
Wygasła	Użytkownik nie ukończył zadania na czas.	Tak

Stany oznaczone gwiazdką (*) mogą być nieostateczne w przypadku, gdy weryfikator popełni błąd i ręcznie zaktualizuje stan.

Poniższy diagram stanu opisuje możliwe przepływy stanu:

W niektórych przypadkach wystawcy mogą nie być w stanie podjąć decyzji na podstawie wstępnych dowodów. Aby ułatwić podjęcie decyzji, użytkownicy mogą zostać poproszeni o dostarczenie dodatkowych informacji lub dowodów do wystawcy. Przykłady wyzwań to m.in. odpowiadanie na listy, odwiedzanie witryny wydawcy lub przesyłanie dodatkowych dowodów.

Jeśli ten zasób zostanie zamodelowany jako tabela bazy danych, będzie wyglądać podobnie do tego:

Uwaga: to nie jest wyczerpujący schemat, ale został przedstawiony w celach poglądowych. W systemie wydawcy prawdopodobnie potrzebna będzie też kolejna tabela do śledzenia wyzwań oraz sposób na powiązanie weryfikacji z urządzeniem.

Dane logowania

Dokument to wirtualna wersja dokumentu fizycznego na konkretnym urządzeniu. Za każdym razem, gdy wirtualne dane logowania są udostępniane na urządzeniu fizycznym, przypisywany jest do nich identyfikator. Jeśli te same fizyczne dane logowania są udostępniane na różnych urządzeniach, za każdym razem będą miały inny identyfikator. Podobnie jeśli dokument zostanie udostępniony na urządzeniu, usunięty i ponownie udostępniony na tym samym urządzeniu, będzie miał inny identyfikator.

Gdy zmienią się dane uwierzytelniające użytkownika (np. adres w dokumencie tożsamości), należy zaktualizować te dane w przypadku wszystkich powiązanych wirtualnych danych uwierzytelniających. Jeden dokument tożsamości może mieć różne wersje odpowiadające takim zmianom. Bieżąca wersja jest śledzona za pomocą identyfikatora wersji danych logowania.

Uwaga: identyfikator danych logowania nie zmienia się przez cały cykl życia danych logowania. Identyfikator wersji dokumentu może się jednak zmienić.

Aby przedstawić dane uwierzytelniające podmiotowi ufającemu, urządzenie musi najpierw pobrać od wystawcy mobilne obiekty zabezpieczeń (MSO). Dokument MSO zawiera skróty danych logowania podpisane przez wydawcę. MSO jest tworzony na podstawie klucza autoryzacji, klucza publicznego wygenerowanego i podpisanego przez klucz tożsamości urządzenia. Klucz autoryzacji skutecznie wiąże dostawcę usług zarządzanych z urządzeniem. Połączenie MSO i danych logowania potwierdza podmiotom polegającym na tych danych, że pochodzą one od wystawcy.

Uwaga: MSO są odrzucane po użyciu. Urządzenia utrzymują pulę MSO, odświeżając ją w razie potrzeby.

Gdy dane logowania zostaną udostępnione na urządzeniu, musi ono wysłać obiekt ProofOfProvisioning z powrotem do wystawcy. Informuje to wydawcę, że dokument został prawidłowo zainstalowany na urządzeniu i jest przechowywany w bezpiecznej pamięci urządzenia.

Uwaga: jako wydawca nie powinieneś udostępniać MSO dla dokumentu tożsamości, dopóki nie otrzymasz ProofOfProvisioning dla tego dokumentu. Dotyczy to również aktualizacji danych logowania.

Dane logowania mogą mieć te stany:

Stan	Opis
ProvisionPending	Dokument został udostępniony w Portfelu Google, ale dowód udostępnienia nie został zwrócony do wystawcy. Dane logowania są przenoszone do tego stanu za każdym razem, gdy zmieni się identyfikator wersji danych logowania. W przypadku tego dokumentu tożsamości nie zostaną wydane żadne MSO.
Aktywne	Dane uwierzytelniające zostały przekazane do Portfela Google, a dowód udostępnienia został zwrócony do wystawcy. MSOs są dostępne dla danych logowania.
Unieważniono	Wydawca trwale unieważnił dane uwierzytelniające. W przypadku tego dokumentu tożsamości nie zostaną wydane żadne MSO. W tym stanie Portfel Google nie będzie wyświetlać dokumentu.
Usunięto	Użytkownik lub Portfel Google trwale usunął dokument z urządzenia. W przypadku tego dokumentu tożsamości nie zostaną wydane żadne MSO. W tym stanie Portfel Google nie będzie wyświetlać dokumentu.

Poniższy diagram stanu opisuje możliwe przepływy stanu:

Jeśli ten zasób zostanie zamodelowany jako tabela bazy danych, będzie wyglądać podobnie do tego:

Uwaga: to nie jest wyczerpujący schemat, ale został przedstawiony w celach poglądowych. W systemie wystawcy prawdopodobnie potrzebna będzie też kolejna tabela do śledzenia MSO oraz sposób powiązania poświadczenia z urządzeniem lub dowodem.