Omówienie architektury Zweryfikowany identyfikator Microsoft Entra
Ważne jest zaplanowanie weryfikowalnego rozwiązania poświadczeń, aby oprócz wystawiania i weryfikowania poświadczeń mieć pełny wgląd w architekturę i wpływ na działalność biznesową rozwiązania. Jeśli jeszcze ich nie przejrzeno, zalecamy zapoznanie się z artykułem Wprowadzenie do Zweryfikowany identyfikator Microsoft Entra i często zadawanych pytań, a następnie ukończ samouczek Wprowadzenie.
W tym omówieniu architektury przedstawiono możliwości i składniki usługi Zweryfikowany identyfikator Microsoft Entra. Aby uzyskać bardziej szczegółowe informacje na temat wystawiania i walidacji, zobacz
Podejścia do tożsamości
Obecnie większość organizacji używa scentralizowanych systemów tożsamości do dostarczania poświadczeń pracowników. Używają również różnych metod, aby zapewnić klientom, partnerom, dostawcom i stronom uzależnionym granice zaufania organizacji. Metody te obejmują federację, tworzenie kont gości i zarządzanie nimi z systemami, takimi jak Microsoft Entra B2B, oraz tworzenie jawnych relacji zaufania z jednostkami uzależnionymi. Większość relacji biznesowych ma składnik cyfrowy, więc umożliwienie pewnej formy zaufania między organizacjami wymaga znacznego nakładu pracy.
Scentralizowane systemy tożsamości
Scentralizowane podejścia nadal działają dobrze w wielu przypadkach, na przykład gdy aplikacje, usługi i urządzenia korzystają z mechanizmów zaufania używanych w domenie lub granicy zaufania.
W scentralizowanych systemach tożsamości dostawca tożsamości (IDP) kontroluje cykl życia i użycie poświadczeń.
Istnieją jednak scenariusze, w których użycie zdecentralizowanej architektury z poświadczeniami weryfikowalnymi może zapewnić wartość dzięki rozszerzaniu kluczowych scenariuszy, takich jak
bezpieczne dołączanie tożsamości pracowników i innych osób, w tym scenariuszy zdalnych.
dostęp do zasobów wewnątrz granicy zaufania organizacji na podstawie określonych kryteriów.
uzyskiwanie dostępu do zasobów spoza granicy zaufania, takich jak uzyskiwanie dostępu do zasobów partnerów, przy użyciu przenośnych poświadczeń wystawionych przez organizację.
Zdecentralizowane systemy tożsamości
W zdecentralizowanych systemach tożsamości kontrola cyklu życia i użycia poświadczeń jest współdzielona między wystawcą, właścicielem i jednostkami uzależnionymi korzystającymi z poświadczeń.
Rozważmy scenariusz na diagramie, w którym proseware, witryna internetowa handlu elektronicznego, chce zaoferować pracownikom Woodgrove rabaty firmowe.
Terminologia dotycząca weryfikowalnych poświadczeń (VCs) może być myląca, jeśli nie znasz komputerów wirtualnych. Poniższe definicje pochodzą z sekcji terminologii Weryfikowalne poświadczenia modelu danych 1.0 . Po każdym z nich odnosimy je do jednostek na powyższym diagramie.
"Wystawca jest rolą, jaką może wykonać jednostka, twierdząc, że oświadczenia dotyczące jednego lub większej liczby podmiotów, tworząc weryfikowalne poświadczenia z tych oświadczeń i przesyłając poświadczenia weryfikowalne do właściciela"."
- Na powyższym diagramie Woodgrove jest wystawcą poświadczeń weryfikowalnych dla swoich pracowników.
"Właściciel jest rolą, jaką może wykonywać jednostka, posiadanie co najmniej jednego weryfikowalnego poświadczenia i generowanie na ich podstawie prezentacji. Posiadacz jest zwykle, ale nie zawsze, przedmiotem weryfikowalnych poświadczeń, które przechowują. Posiadacze przechowują swoje poświadczenia w repozytoriach poświadczeń".
- Na powyższym diagramie Alice jest pracownikiem Woodgrove. Uzyskali poświadczenia weryfikowalne od wystawcy Woodgrove i są posiadaczem tego poświadczenia.
"Weryfikator jest rolą wykonywaną przez odbieranie co najmniej jednego weryfikowalnego poświadczenia, opcjonalnie wewnątrz weryfikowalnej prezentacji na potrzeby przetwarzania. Inne specyfikacje mogą odnosić się do tej koncepcji jako jednostki uzależnionej.
- Na powyższym diagramie proseware jest weryfikatorem poświadczeń wystawionych przez Woodgrove.
"Poświadczenie jest zestawem co najmniej jednego oświadczenia złożonego przez wystawcę. Weryfikowalne poświadczenie to poświadczenie umożliwiające wykrycie naruszenia, które ma uprawnienia do kryptograficznego zweryfikowania. Poświadczenia weryfikowalne mogą służyć do tworzenia weryfikowalnych prezentacji, które mogą być również weryfikowane kryptograficznie. Oświadczenia w poświadczeniu mogą dotyczyć różnych podmiotów.
"Zdecentralizowany identyfikator jest przenośnym identyfikatorem opartym na identyfikatorze URI, znanym również jako DID, skojarzonym z jednostką. Te identyfikatory są często używane w poświadczeniach weryfikowalnych i są skojarzone z podmiotami, wystawcami i weryfikatorami".
"Zdecentralizowany dokument identyfikatora, nazywany również dokumentem DID, jest dokumentem dostępnym przy użyciu weryfikowalnego rejestru danych i zawiera informacje związane z określonym zdecentralizowanym identyfikatorem, takim jak skojarzone repozytorium i informacje o kluczu publicznym".
W scenariuszu zarówno wystawca, jak i weryfikator mają dokument DID i DID. Dokument DID zawiera klucz publiczny oraz listę domen internetowych DNS skojarzonych z domenami DID (nazywanymi również połączonymi domenami).
Woodgrove (wystawca) podpisuje swoje komputery wirtualne pracowników przy użyciu klucza prywatnego; podobnie proseware (weryfikator) podpisuje żądania przedstawienia VC przy użyciu jego klucza, który jest również skojarzony z jego DID.
System zaufania jest podstawą ustanawiania zaufania między zdecentralizowanych systemów. Może to być rejestr rozproszony lub może być czymś scentralizowanym, takim jak DID Web.
"Rejestr rozproszony jest systemem niecentralizowanym do rejestrowania zdarzeń. Systemy te określają wystarczającą pewność, aby uczestnicy polegali na danych zarejestrowanych przez inne osoby w celu podejmowania decyzji operacyjnych. Zazwyczaj używają rozproszonych baz danych, w których różne węzły używają protokołu konsensusu w celu potwierdzenia kolejności transakcji podpisanych kryptograficznie. Łączenie cyfrowo podpisanych transakcji w czasie często sprawia, że historia rejestru jest skutecznie niezmienna.
Łączenie scentralizowanych i zdecentralizowanych architektur tożsamości
Podczas badania weryfikowalnego rozwiązania poświadczeń warto zrozumieć, jak zdecentralizowane architektury tożsamości można połączyć ze scentralizowanymi architekturami tożsamości w celu zapewnienia rozwiązania, które zmniejsza ryzyko i oferuje znaczne korzyści operacyjne.
Podróż użytkownika
Ten przegląd architektury jest zgodny z podróżą kandydata do pracy i pracownika, który ubiega się o zatrudnienie w organizacji i akceptuje go. Następnie następuje po pracownikach i organizacji poprzez zmiany, w których poświadczenia weryfikowalne mogą rozszerzać scentralizowane procesy.
Aktorzy w tych przypadkach użycia
Alice, osoba ubiegająca się o zatrudnienie z Woodgrove, Inc.
Woodgrove, Inc, fikcyjna firma.
Adatum, fikcyjny partner weryfikacji tożsamości Woodgrove.
Proseware, fikcyjna organizacja partnerska Woodgrove.
Rozwiązanie Woodgrove korzysta zarówno ze scentralizowanych, jak i zdecentralizowanych architektur tożsamości.
Kroki w podróży użytkownika
Alicja ubiega się o stanowisko, przyjmowania i dołączania do stanowiska z Woodgrove, Inc.
Uzyskiwanie dostępu do zasobów cyfrowych w granicach zaufania woodgrove'a.
Uzyskiwanie dostępu do zasobów cyfrowych poza granicą zaufania Woodgrove'a bez rozszerzania granic zaufania woodgrove lub partnerów.
Ponieważ firma Woodgrove nadal prowadzi swoją działalność, musi stale zarządzać tożsamościami. Przypadki użycia w tych wskazówkach opisują, jak Alicja może używać funkcji samoobsługowych do uzyskiwania i utrzymywania ich identyfikatorów oraz sposobu dodawania, modyfikowania i kończenia relacji biznesowych z różnymi wymaganiami dotyczącymi zaufania.
W takich przypadkach użycia pokazano, jak można połączyć scentralizowane tożsamości i zdecentralizowane tożsamości, aby zapewnić bardziej niezawodną i wydajną strategię i cykl życia tożsamości oraz zaufania.
Podróż użytkownika: dołączanie do woodgrove
Świadomość: Alice jest zainteresowana pracą dla Woodgrove, Inc. i odwiedza witrynę internetową Woodgrove'a.
Aktywacja: Witryna Woodgrove przedstawia Alice z metodą potwierdzenia swojej tożsamości, monitując ich o kod QR lub link bezpośredni, aby odwiedzić zaufanego partnera sprawdzającego tożsamość, Adatum.
Żądanie i przekazanie: Adatum żąda potwierdzenia tożsamości od Alice. Alice robi selfie i zdjęcie prawa jazdy i przekazuje je do Adatum.
Wystawianie: Gdy Adatum zweryfikuje tożsamość Alicji, Adatum wystawia Alice weryfikowalne poświadczenie (VC) potwierdzające ich tożsamość.
Prezentacja: Alice (posiadacz i podmiot poświadczeń) może następnie uzyskać dostęp do portalu kariery Woodgrove w celu ukończenia procesu aplikacji. Gdy Alicja używa vc do uzyskiwania dostępu do portalu, Woodgrove przejmuje role weryfikatora i jednostki uzależnionej, ufając zaświadczeniu z Adatum.
Dystrybucja poświadczeń początkowych
Alicja akceptuje zatrudnienie z Woodgrove. W ramach procesu dołączania konto Microsoft Entra jest tworzone dla Alicji do użycia w granicach zaufania Woodgrove. Menedżer Alice musi dowiedzieć się, jak włączyć Alice, która działa zdalnie, aby otrzymywać wstępne informacje logowania w bezpieczny sposób. W przeszłości dział IT mógł dostarczyć te poświadczenia do swojego menedżera, który będzie je drukować i przekazać je Alicji. Drukowanie poświadczeń nie działa z pracownikami zdalnymi.
Komputery wirtualne mogą dodać wartość do scentralizowanych systemów przez rozszerzenie procesu dystrybucji poświadczeń. Zamiast wymagać od menedżera podania poświadczeń, Alice może użyć swojego vc jako dowodu tożsamości, aby otrzymać początkową nazwę użytkownika i poświadczenia dla scentralizowanego dostępu do systemów. Alice przedstawia dowód tożsamości, którą dodali do swojego portfela w ramach procesu dołączania.
W przypadku użycia dołączania role relacji zaufania są dystrybuowane między wystawcą, weryfikatorem i posiadaczem.
Wystawca jest odpowiedzialny za weryfikację oświadczeń, które są częścią wystawianego vc. Adatum weryfikuje tożsamość Alicji, aby wydać VC. W takim przypadku maszyny wirtualne są wystawiane bez uwzględnienia weryfikatora lub jednostki uzależnionej.
Posiadacz posiada VC i inicjuje prezentację VC do weryfikacji. Tylko Alice może prezentować komputery wirtualne, które posiada.
Weryfikator akceptuje oświadczenia w vc od wystawców, którym ufają, i weryfikuje vc przy użyciu zdecentralizowanej funkcji rejestru opisanej w modelu danych weryfikowalnych poświadczeń. Woodgrove ufa twierdzeniom Adatuma o tożsamości Alicji.
Łącząc scentralizowane i zdecentralizowane architektury tożsamości na potrzeby dołączania, uprzywilejowane informacje o Alicji niezbędne do weryfikacji tożsamości, takie jak numer identyfikatora rządu, nie muszą być przechowywane przez Woodgrove, ponieważ ufają, że vc Alicji wystawione przez partnera weryfikacji tożsamości (Adatum) potwierdza swoją tożsamość. Duplikowanie nakładu pracy jest zminimalizowane, a można zaimplementować programowe i przewidywalne podejście do początkowych zadań dołączania.
Podróż użytkownika: uzyskiwanie dostępu do zasobów wewnątrz granicy zaufania
Jako pracownik Alice działa w granicach zaufania Woodgrove. Woodgrove działa jako dostawca tożsamości (IDP) i utrzymuje pełną kontrolę nad tożsamością i konfiguracją aplikacji, których Alicja używa do interakcji w granicach zaufania Woodgrove. Aby korzystać z zasobów w granicach zaufania identyfikatora Entra firmy Microsoft, Alicja udostępnia potencjalnie wiele form dowodu identyfikacji w celu zalogowania się do granicy zaufania woodgrove'a i uzyskania dostępu do zasobów wewnątrz środowiska technologicznego woodgrove'a. Wiele dowodów jest typowym scenariuszem, który jest dobrze obsługiwany przy użyciu scentralizowanej architektury tożsamości.
Woodgrove zarządza granicą zaufania i używa dobrych rozwiązań w zakresie zabezpieczeń zapewnia najmniej uprzywilejowany poziom dostępu do Alicji na podstawie wykonanego zadania. Aby zachować wysoki poziom zabezpieczeń i potencjalnie ze względów zgodności, woodgrove musi również mieć możliwość śledzenia uprawnień pracowników i dostępu do zasobów oraz musi mieć możliwość odwołania uprawnień po zakończeniu zatrudnienia.
Alicja używa tylko poświadczeń utrzymywanych przez woodgrove w celu uzyskania dostępu do zasobów Woodgrove. Alice nie ma potrzeby śledzenia, kiedy poświadczenia są używane, ponieważ woodgrove zarządza poświadczeniami i jest używany tylko z zasobami Woodgrove. Tożsamość jest prawidłowa tylko wewnątrz granicy zaufania Woodgrove, gdy jest wymagany dostęp do zasobów Woodgrove, więc Alicja nie musi posiadać poświadczeń.
Korzystanie z maszyn wirtualnych wewnątrz granicy zaufania
Indywidualni pracownicy mają zmieniające się potrzeby dotyczące tożsamości, a komputery wirtualne mogą rozszerzyć scentralizowane systemy w celu zarządzania tymi zmianami.
Chociaż zatrudniony przez Woodgrove Alice może potrzebować dostępu do zasobów na podstawie spełnienia określonych wymagań. Na przykład po ukończeniu szkolenia dotyczącego prywatności Alicja może wydać nowego pracownika VC z tym oświadczeniem, a vc może służyć do uzyskiwania dostępu do ograniczonych zasobów.
Komputery wirtualne mogą być używane w granicach zaufania na potrzeby odzyskiwania konta. Jeśli na przykład pracownik utracił telefon i komputer, może odzyskać dostęp, uzyskując nowe vc z usługi weryfikacji tożsamości, która jest zaufana przez woodgrove, a następnie użyć tego vc, aby uzyskać nowe poświadczenia.
Podróż użytkownika: uzyskiwanie dostępu do zasobów zewnętrznych
Woodgrove negocjuje rabat na zakup produktu z proseware. Wszyscy pracownicy Woodgrove kwalifikują się do rabatu. Woodgrove chce zapewnić Alice sposób na dostęp do witryny internetowej Proseware i otrzymać rabat na zakupione produkty. Jeśli firma Woodgrove korzysta ze scentralizowanej architektury tożsamości, istnieją dwa podejścia do zapewnienia rabatu Alicji:
Alicja może podać dane osobowe, aby utworzyć konto z proseware, a następnie Proseware musiałby zweryfikować zatrudnienie Alicji z Woodgrove.
Woodgrove może rozszerzyć granicę zaufania, aby uwzględnić Proseware jako jednostkę uzależnioną, a Alice może użyć rozszerzonej granicy zaufania, aby otrzymać rabat.
Dzięki zdecentralizowanym identyfikatorom Woodgrove może zapewnić Alicji weryfikowalne poświadczenia (VC), których Alicja może używać do uzyskiwania dostępu do witryny internetowej proseware i innych zasobów zewnętrznych.
Dostarczając Alice VC, Woodgrove potwierdza, że Alice jest pracownikiem. Woodgrove jest zaufanym wystawcą VC w rozwiązaniu weryfikacji proseware. To zaufanie do procesu wystawiania Woodgrove pozwala Proseware elektronicznie zaakceptować VC jako dowód, że Alice jest pracownikiem Woodgrove i zapewnić Alice rabat. W ramach weryfikacji vc Alice przedstawia, Proseware sprawdza ważność VC przy użyciu systemu zaufania. W tym rozwiązaniu:
Woodgrove umożliwia Alice zapewnienie proseware dowód zatrudnienia bez Woodgrove konieczności rozszerzenia granicy zaufania.
Proseware nie musi rozszerzać granicy zaufania, aby zweryfikować Alice jest pracownikiem Woodgrove. Proseware może użyć VC, które Woodgrove zapewnia. Ponieważ granica zaufania nie jest rozszerzona, zarządzanie relacją zaufania jest łatwiejsze, a oprogramowanie Proseware może łatwo zakończyć relację, nie akceptując już komputerów wirtualnych.
Alicja nie musi dostarczać danych osobowych proseware, takich jak wiadomość e-mail. Alicja utrzymuje VC w aplikacji portfelowej na urządzeniu osobistym. Jedyną osobą, która może używać VC, jest Alicja, a Alicja musi zainicjować użycie poświadczeń. Każde użycie VC jest rejestrowane przez aplikację portfela, więc Alicja ma rekord, kiedy i gdzie jest używany VC.
Łącząc scentralizowane i zdecentralizowane architektury tożsamości do obsługi wewnątrz i poza granicami zaufania w usłudze Woodgrove, złożoność i ryzyko można zmniejszyć, a ograniczone relacje stają się łatwiejsze do zarządzania.
Zmiany w czasie
Woodgrove dodaje nowe i kończy bieżące relacje biznesowe z innymi organizacjami i musi określić, kiedy są używane scentralizowane i zdecentralizowane architektury tożsamości.
Łącząc scentralizowane i zdecentralizowane architektury tożsamości, odpowiedzialność i wysiłek związany z tożsamością i weryfikacją tożsamości są dystrybuowane, a ryzyko jest niższe. Użytkownik nie ryzykuje zwalniania swoich prywatnych informacji tak często, jak i do tylu nieznanych weryfikatora. Szczególnie:
- W scentralizowanych architekturach tożsamości dostawcy tożsamości wystawiają poświadczenia i przeprowadzają weryfikację tych wystawionych poświadczeń. Dostawcy tożsamości przetwarzają informacje o wszystkich tożsamościach. Przechowuje je w katalogu lub pobiera je z katalogu. Opcjonalnie dostawcy tożsamości mogą akceptować tokeny zabezpieczające z innych systemów dostawcy tożsamości, takich jak logowania społecznościowe lub partnerzy biznesowi. Aby jednostka uzależniona korzystała z tożsamości w granicach zaufania dostawcy tożsamości, musi być skonfigurowana tak, aby akceptowała tokeny wystawione przez dostawcę tożsamości.
Jak działają zdecentralizowane systemy tożsamości
W zdecentralizowanych architekturach tożsamości wystawca, użytkownik i jednostka uzależniona (RP) mają rolę w ustanawianiu i zapewnianiu ciągłej zaufanej wymiany poświadczeń. Klucze publiczne diD aktorów są rozpoznawalne za pośrednictwem systemu zaufania, który umożliwia walidację podpisu i w związku z tym zaufanie do dowolnego artefaktu, w tym poświadczenia weryfikowalne. Jednostki uzależnione mogą korzystać z weryfikowalnych poświadczeń bez ustanawiania relacji zaufania z wystawcą. Zamiast tego wystawca dostarcza podmiotowi poświadczenia do przedstawienia jako dowód dla jednostek uzależnionych. Wszystkie wiadomości między aktorami są podpisane przy użyciu funkcji DID aktora; Identyfikatory DID od wystawców i weryfikatorów muszą również posiadać domeny DNS, które wygenerowały żądania.
Na przykład: Gdy posiadacze VC muszą uzyskać dostęp do zasobu, muszą przedstawić vc tej jednostki uzależnionej. Robią to za pomocą aplikacji portfelowej w celu odczytania żądania RP w celu przedstawienia VC. W ramach odczytywania żądania aplikacja portfel używa żądania DID rp do znalezienia kluczy publicznych rp przy użyciu systemu zaufania, sprawdzania, czy żądanie przedstawienia VC nie zostało naruszone. Aby udowodnić własność domeny, portfel sprawdza również, czy did jest przywoływany w dokumencie metadanych hostowanym w domenie DNS rp.
Przepływ 1. Weryfikowanie wystawiania poświadczeń
W tym przepływie właściciel poświadczeń współdziała z wystawcą, aby zażądać weryfikowalnego poświadczenia, jak pokazano na poniższym diagramie
Posiadacz uruchamia przepływ przy użyciu przeglądarki lub aplikacji natywnej w celu uzyskania dostępu do frontonu internetowego wystawcy. W tym miejscu witryna internetowa wystawcy kieruje użytkownika do zbierania danych i wykonywania logiki specyficznej dla wystawcy w celu określenia, czy można wydać poświadczenia, i jego zawartości.
Fronton internetowy wystawcy wywołuje usługę Zweryfikowany identyfikator Microsoft Entra w celu wygenerowania żądania wystawiania VC.
Fronton internetowy renderuje link do żądania jako kod QR lub link bezpośredni specyficzny dla urządzenia (w zależności od urządzenia).
Posiadacz skanuje kod QR lub link bezpośredni z kroku 3 przy użyciu aplikacji Portfel, takiej jak Microsoft Authenticator
Portfel pobiera żądanie z linku. Żądanie obejmuje:
CZY wystawcy. Identyfikator DID wystawcy jest używany przez aplikację portfel do rozpoznawania za pośrednictwem systemu zaufania w celu znalezienia kluczy publicznych i połączonych domen.
Adres URL manifestu VC, który określa wymagania kontraktu dotyczące wystawiania VC. Wymaganie dotyczące kontraktu może obejmować id_token, atrybuty testowane samodzielnie, które muszą zostać dostarczone, lub prezentację innego vc.
Wygląd i działanie VC (adres URL pliku logo, kolory itp.).
Portfel weryfikuje żądania wystawiania i przetwarza wymagania dotyczące kontraktu:
Sprawdza, czy komunikat żądania wystawiania jest podpisany przez klucze wystawcy znalezione w dokumencie DID rozpoznane za pośrednictwem systemu zaufania. Sprawdzanie poprawności podpisu gwarantuje, że wiadomość nie została naruszona.
Sprawdza, czy wystawca jest właścicielem domeny DNS, do którego odwołuje się dokument DID wystawcy.
W zależności od wymagań kontraktu VC portfel może wymagać od posiadacza zbierania dodatkowych informacji, na przykład z prośbą o własne atrybuty lub nawigowanie po przepływie OIDC w celu uzyskania id_token.
Przesyła artefakty wymagane przez kontrakt do usługi Zweryfikowany identyfikator Microsoft Entra. Usługa Zweryfikowany identyfikator Microsoft Entra zwraca vc, podpisany przy użyciu klucza DID wystawcy, a portfel bezpiecznie przechowuje VC.
Aby uzyskać szczegółowe informacje na temat tworzenia rozwiązania wystawiania i zagadnień dotyczących architektury, zobacz Planowanie rozwiązania do wystawiania Zweryfikowany identyfikator Microsoft Entra.
Przepływ 2. Weryfikowalna prezentacja poświadczeń
W tym przepływie posiadacz wchodzi w interakcję z jednostki uzależnionej (RP), aby przedstawić VC w ramach wymagań dotyczących autoryzacji.
Posiadacz uruchamia przepływ przy użyciu przeglądarki lub aplikacji natywnej w celu uzyskania dostępu do frontonu internetowego jednostki uzależnionej.
Fronton internetowy wywołuje usługę Zweryfikowany identyfikator Microsoft Entra w celu wygenerowania żądania prezentacji VC.
Fronton internetowy renderuje link do żądania jako kod QR lub link bezpośredni specyficzny dla urządzenia (w zależności od urządzenia).
Posiadacz skanuje kod QR lub link bezpośredni z kroku 3 przy użyciu aplikacji portfelowej, takiej jak Microsoft Authenticator
Portfel pobiera żądanie z linku. Żądanie obejmuje:
żądanie oparte na standardach dla poświadczeń schematu lub typu poświadczeń.
DID RP, który portfel wyszukuje w systemie zaufania.
Portfel sprawdza, czy żądanie prezentacji i znajduje przechowywane vc(s), które spełniają żądanie. Na podstawie wymaganych maszyn wirtualnych portfel prowadzi podmiot do wybierania i wyrażania zgody na korzystanie z maszyn wirtualnych.
- Podmiot wyraża zgodę na udostępnianie vc do rp
Następnie portfel wysyła ładunek odpowiedzi prezentacji do usługi Zweryfikowany identyfikator Microsoft Entra podpisanej przez temat. Zawiera:
Podmiot wyraził zgodę na vc(s).
Temat DID.
RP DID jako "odbiorcy" ładunku.
Usługa Zweryfikowany identyfikator Microsoft Entra weryfikuje odpowiedź wysłaną przez portfel. W niektórych przypadkach wystawca VC może odwołać vc. Aby upewnić się, że vc jest nadal prawidłowe, weryfikator musi sprawdzić się z wystawcą VC. Zależy to od tego, jak weryfikator poprosił o vc w kroku 2.
Po weryfikacji usługa Zweryfikowany identyfikator Microsoft Entra wywołuje ponownie rp z wynikiem.
Aby uzyskać szczegółowe informacje na temat tworzenia rozwiązania do weryfikacji i zagadnień dotyczących architektury, zobacz Planowanie rozwiązania weryfikacji Zweryfikowany identyfikator Microsoft Entra.
Kluczowe wnioski
Architektury zdecentralizowane mogą służyć do ulepszania istniejących rozwiązań i zapewnienia nowych możliwości.
Aby zrealizować aspiracje zdecentralizowanej platformy Identity Foundation (DIF) i projektu W3C, należy wziąć pod uwagę następujące elementy podczas tworzenia weryfikowalnego rozwiązania poświadczeń:
Nie ma centralnych punktów zaufania między podmiotami w systemie. Oznacza to, że granice zaufania nie są rozszerzane za pośrednictwem federacji, ponieważ aktorzy ufają określonym komputerom wirtualnym.
- System zaufania umożliwia odnajdywanie identyfikatora zdecentralizowanego dowolnego aktora (DID).
Rozwiązanie umożliwia weryfikatorom weryfikowanie wszystkich weryfikowalnych poświadczeń (VCs) z dowolnego wystawcy.
Rozwiązanie nie umożliwia wystawcy kontrolowania autoryzacji podmiotu lub weryfikatora (jednostki uzależnionej).
Aktorzy działają w sposób oddzielony, każdy z nich może wykonywać zadania dla swoich ról.
Wystawcy serwisują każde żądanie VC i nie dyskryminują żądań, które są obsługiwane.
Podmioty posiadają swoje VC po wydaniu i mogą przedstawić swoje vc do dowolnego weryfikatora.
Weryfikatory mogą weryfikować dowolne vc z dowolnego podmiotu lub wystawcy.
Następne kroki
Dowiedz się więcej o architekturze dla weryfikowalnych poświadczeń