Udostępnij za pośrednictwem


Planowanie rozwiązania do wystawiania Zweryfikowany identyfikator Microsoft Entra

Ważne jest, aby zaplanować rozwiązanie wystawiania, aby oprócz wystawiania poświadczeń mieć pełny widok wpływu architektury i działalności rozwiązania. Jeśli nie zostało to zrobione, zalecamy wyświetlenie przeglądu architektury Zweryfikowany identyfikator Microsoft Entra w celu uzyskania podstawowych informacji.

Zakres wskazówek

W tym artykule opisano techniczne aspekty planowania rozwiązania do weryfikowania wystawiania poświadczeń. Rozwiązanie firmy Microsoft do weryfikowania poświadczeń jest zgodne ze standardami World Wide Web Consortium (W3C) Verifiable Credentials Data Model 1.0 i Zdecentralizowane identyfikatory (DID) w wersji 1.0, co umożliwia współdziałanie z nie usługi firmy Microsoft. Jednak przykłady w tej zawartości odzwierciedlają stos rozwiązań firmy Microsoft na potrzeby weryfikowalnych poświadczeń.

Poza zakresem tej zawartości są artykuły obejmujące technologie pomocnicze, które nie są specyficzne dla rozwiązań wystawiania. Na przykład witryny internetowe są używane w weryfikowalnym rozwiązaniu do wystawiania poświadczeń, ale planowanie wdrożenia witryny internetowej nie zostało szczegółowo omówione.

Składniki rozwiązania

W ramach planu rozwiązania wystawiania należy zaprojektować rozwiązanie, które umożliwia interakcję między wystawcą, użytkownikiem i weryfikatorem. Na poniższym diagramie przedstawiono składniki architektury wystawiania.

Architektura rozwiązania do wystawiania vc firmy Microsoft

Diagram przedstawiający różne składniki rozwiązania wystawiania.

Dzierżawa Microsoft Entra

Wymagania wstępne dotyczące uruchamiania usługi Zweryfikowany identyfikator Microsoft Entra są hostowane w dzierżawie firmy Microsoft Entra. Dzierżawa firmy Microsoft Entra udostępnia płaszczyznę kontroli zarządzania tożsamościami i dostępem (IAM) dla zasobów platformy Azure, które są częścią rozwiązania.

Każda dzierżawa używa wielodostępnej usługi Zweryfikowany identyfikator Microsoft Entra i ma zdecentralizowany identyfikator (DID). Did zapewnia dowód, że wystawca jest właścicielem domeny włączonej do did. Did jest używany przez podmiot i weryfikator do sprawdzania poprawności wystawcy.

Usługi platformy Microsoft Azure

Diagram przedstawiający składniki rozwiązania wystawiania, koncentrujące się na usługach platformy Azure.

Usługa Azure Key Vault przechowuje klucze wystawcy, które są generowane podczas inicjowania usługi wystawiania Zweryfikowany identyfikator Microsoft Entra. Klucze i metadane są używane do wykonywania operacji zarządzania poświadczeniami i zapewnienia zabezpieczeń komunikatów.

Każdy wystawca ma jeden zestaw kluczy używany do podpisywania, aktualizowania i odzyskiwania. Ten zestaw kluczy jest używany dla każdego wystawiania każdego weryfikowalnego poświadczenia, które tworzysz.

usługa Zweryfikowany identyfikator Microsoft Entra służy do przechowywania metadanych i definicji poświadczeń, a w szczególności reguł i wyświetlania definicji dla poświadczeń.

  • Definicje wyświetlania określają, jak oświadczenia są wyświetlane w portfelu posiadacza, a także obejmują znakowanie i inne elementy. Definicja wyświetlania może być zlokalizowana w wielu językach. Zobacz Jak dostosować poświadczenia weryfikowalne.

  • Reguły to model zdefiniowany przez wystawcę, który opisuje wymagane dane wejściowe poświadczenia weryfikowalnego. Reguły zdefiniowały również zaufane źródła danych wejściowych oraz mapowanie oświadczeń wejściowych na oświadczenia wyjściowe przechowywane w vc. W zależności od typu zaświadczania zdefiniowanego w definicji reguł oświadczenia wejściowe mogą pochodzić od różnych dostawców. Oświadczenia wejściowe mogą pochodzić z dostawcy tożsamości OIDC, z id_token_hint lub z oświadczeń samodzielnie aserowanych podczas wystawiania za pośrednictwem danych wejściowych użytkownika w portfelu.

    • Dane wejściowe — to podzbiór modelu w pliku reguł na potrzeby użycia klienta. Podzestaw musi opisywać zestaw danych wejściowych, gdzie uzyskać dane wejściowe i punkt końcowy w celu wywołania w celu uzyskania weryfikowalnego poświadczenia.

usługa Zweryfikowany identyfikator Microsoft Entra

Diagram usługi Zweryfikowany identyfikator Microsoft Entra.

Usługa Zweryfikowany identyfikator Microsoft Entra umożliwia wystawianie i odwoływanie maszyn wirtualnych na podstawie konfiguracji. Usługa:

  • Aprowizuje identyfikator zdecentralizowany (DID). Każdy wystawca ma jeden identyfikator DID na dzierżawę.

  • Aprowizuje zestawy kluczy w usłudze Key Vault.

  • Przechowuje metadane konfiguracji używane przez usługę wystawiania i aplikację Microsoft Authenticator.

  • Udostępnia interfejsy API REST dla frontonów internetowych wystawcy i weryfikatora

System zaufania

Zrzut ekranu przedstawiający system zaufania w architekturze.

Zweryfikowany identyfikator Microsoft Entra obecnie obsługuje sieć Web jako system zaufaniaDID Web, gdzie dokument DID jest hostowany na serwerze internetowym wystawców.

Aplikacja Microsoft Authenticator

Diagram przedstawiający aplikację Microsoft Authenticator jako portfel rozwiązania weryfikowalnego poświadczeń.

Microsoft Authenticator to aplikacja mobilna. Aplikacja Authenticator organizuje interakcje między użytkownikiem, usługą Zweryfikowany identyfikator Microsoft Entra a kontraktem używanym do wystawiania komputerów wirtualnych. Działa jako portfel cyfrowy, w którym posiadacz VC przechowuje VC, w tym klucz prywatny podmiotu VC. Authenticator jest również mechanizmem używanym do prezentowania komputerów wirtualnych do weryfikacji.

Logika biznesowa wystawiania

Diagram przedstawiający logikę biznesową wystawiania zweryfikowanego identyfikatora.

Rozwiązanie wystawiania obejmuje fronton internetowy, w którym użytkownicy żądają vc, magazynu tożsamości i innego magazynu atrybutów w celu uzyskania wartości oświadczeń dotyczących tematu i innych usług zaplecza.

Fronton internetowy obsługuje żądania wystawiania do portfela podmiotu przez generowanie linków bezpośrednich lub kodów QR. Na podstawie konfiguracji kontraktu inne składniki mogą być wymagane do spełnienia wymagań dotyczących tworzenia vc.

Te usługi zapewniają role pomocnicze, które nie muszą być zintegrowane z usługą wystawiania Zweryfikowany identyfikator Microsoft Entra. Ta warstwa zazwyczaj obejmuje następujące elementy:

  • Usługa lub usługi zgodne z protokołem OpenID Connect (OIDC) są używane do uzyskiwania id_tokens potrzebnych do wystawienia vc. Istniejące systemy tożsamości, takie jak Microsoft Entra ID lub Azure AD B2C, mogą zapewnić usługę zgodną ze standardem OIDC, ponieważ mogą być rozwiązaniami niestandardowymi, takimi jak Identity Server.

  • Magazyny atrybutów — magazyny atrybutów mogą znajdować się poza usługami katalogowymi i udostępniać atrybuty potrzebne do wystawienia vc. Na przykład system informacji o uczniach może dostarczyć oświadczenia dotyczące stopni uzyskanych.

  • Dodatkowe usługi warstwy środkowej, które zawierają reguły biznesowe na potrzeby wyszukiwania, weryfikowania, rozliczeń i innych testów i przepływów pracy środowiska uruchomieniowego wymaganych do wystawiania poświadczeń.

Aby uzyskać więcej informacji na temat konfigurowania frontonu internetowego, zobacz samouczek Konfigurowanie identyfikatora entra firmy Microsoft w celu wystawiania weryfikowalnych poświadczeń.

Zagadnienia dotyczące projektowania poświadczeń

Konkretne przypadki użycia określają projekt poświadczeń. Przypadek użycia określa:

  • wymagania dotyczące współdziałania

  • sposób, w jaki użytkownicy muszą udowodnić swoją tożsamość, aby uzyskać swoje vc

  • oświadczenia wymagane w poświadczeniach

  • jeśli należy odwołać poświadczenia

Przypadki użycia poświadczeń

W przypadku Zweryfikowany identyfikator Microsoft Entra najbardziej typowe przypadki użycia poświadczeń to:

Weryfikacja tożsamości: poświadczenia są wystawiane na podstawie wielu kryteriów. Wiele kryteriów może obejmować weryfikację autentyczności dokumentów wydanych przez rząd, takich jak paszport lub prawo jazdy, i korelowanie informacji w tym dokumencie z innymi informacjami, takimi jak:

  • selfie użytkownika

  • weryfikacja życia

Tego rodzaju poświadczenia są dobrym rozwiązaniem w przypadku scenariuszy dołączania tożsamości nowych pracowników, partnerów, dostawców usług, uczniów i innych wystąpień, w których weryfikacja tożsamości jest niezbędna.

Diagram przedstawiający przypadek użycia weryfikacji tożsamości.

Dowód zatrudnienia/członkostwa: poświadczenie jest wystawiane w celu udowodnienia relacji między użytkownikiem a instytucją. Tego rodzaju poświadczenia są dobrym rozwiązaniem do uzyskiwania dostępu do luźno powiązanych aplikacji biznesowych, takich jak sprzedawcy detaliczni oferujący rabaty dla pracowników lub studentów. Jedną z głównych wartości wirtualnych jest ich przenośność: po wystawieniu użytkownik może używać vc w wielu scenariuszach.

Diagram przedstawiający dowód przypadku użycia zatrudnienia.

Aby uzyskać więcej przypadków użycia, zobacz Weryfikowalne przypadki użycia poświadczeń (w3.org).

Współdziałanie poświadczeń

W ramach procesu projektowania zbadaj schematy specyficzne dla branży, przestrzenie nazw i identyfikatory, do których można dopasować się do zmaksymalizowania współdziałania i użycia. Przykłady można znaleźć w Schema.org i DIF — oświadczenia i poświadczenia grupy roboczej.

Typowe schematy to obszar, w którym nadal pojawiają się standardy. Przykładem takiego wysiłku jest weryfikowalne poświadczenia dla edukacji grupy zadaniowej. Zachęcamy do badania i współtworzenia nowych standardów w branży organizacji.

Typ i atrybuty poświadczeń

Po ustanowieniu przypadku użycia poświadczeń należy zdecydować o typie poświadczeń i atrybutach do uwzględnienia w poświadczeniu. Weryfikatory mogą odczytywać oświadczenia w vc przedstawionym przez użytkowników.

Wszystkie poświadczenia weryfikowalne muszą zadeklarować ich typ w definicji reguł. Typ poświadczeń rozróżnia weryfikowalny schemat poświadczeń od innych poświadczeń i zapewnia współdziałanie wystawców i weryfikatorów. Aby wskazać typ poświadczeń, podaj co najmniej jeden typ poświadczeń, który spełnia poświadczenie. Każdy typ jest unikatowym ciągiem. Często identyfikator URI jest używany do zapewnienia globalnej unikatowości. Identyfikator URI nie musi być adresowalny. Jest on traktowany jako ciąg. Na przykład poświadczenie dyplomu wydane przez Contoso University może zadeklarować następujące typy:

Typ Cel
https://schema.org/EducationalCredential Deklaruje, że dyplomy wydane przez Contoso University zawierają atrybuty zdefiniowane przez obiekt schema.org EducationaCredential .
https://schemas.ed.gov/universityDiploma2020 Deklaruje, że dyplomy wydane przez Contoso University zawierają atrybuty zdefiniowane przez Departament Edukacji USA.
https://schemas.contoso.edu/diploma2020 Deklaruje, że dyplomy wydane przez Contoso University zawierają atrybuty zdefiniowane przez Contoso University.

Oprócz standardów i schematów specyficznych dla branży, które mogą mieć zastosowanie do Twoich scenariuszy, należy wziąć pod uwagę następujące aspekty:

  • Zminimalizuj informacje prywatne: poznaj przypadki użycia z minimalną ilością niezbędnych informacji prywatnych. Na przykład vc używane na potrzeby witryn internetowych handlu elektronicznego, które oferują rabaty dla pracowników i absolwentów, można spełnić, przedstawiając poświadczenie tylko przy użyciu oświadczeń pierwszego i nazwiska. Dodatkowe informacje, takie jak data zatrudnienia, tytuł, dział, nie są potrzebne.

  • Faworyzowanie oświadczeń abstrakcyjnych: każde oświadczenie powinno spełniać potrzebę, jednocześnie minimalizując szczegóły. Na przykład oświadczenie o nazwie "ageOver" z dyskretnymi wartościami, takimi jak 13, 21, 60, jest bardziej abstrakcyjne niż data roszczenia urodzenia.

  • Planowanie możliwości wywołania: zalecamy zdefiniowanie oświadczenia indeksu w celu umożliwienia mechanizmom znajdowania i odwoływania poświadczeń. Definiowanie jednego oświadczenia indeksu na kontrakt jest ograniczone do definiowania jednego oświadczenia indeksu. Należy pamiętać, że wartości indeksowanych oświadczeń nie są przechowywane w zapleczu, tylko skrót wartości oświadczenia. Aby uzyskać więcej informacji, zobacz Odwoływanie wcześniej wystawionych poświadczeń weryfikowalnych.

Aby zapoznać się z innymi zagadnieniami dotyczącymi atrybutów poświadczeń, zapoznaj się ze specyfikacją Verifiable Credentials Data Model 1.0 (w3.org).

Planowanie atrybutów jakości

Planowanie wydajności

Podobnie jak w przypadku dowolnego rozwiązania, należy zaplanować wydajność. Kluczowymi obszarami, na których należy skupić się, są opóźnienia i skalowalność. W początkowych fazach cyklu wydawania wydajność nie powinna być istotna. Jednak gdy wdrożenie rozwiązania wystawiania powoduje wystawienie wielu weryfikowalnych poświadczeń, planowanie wydajności może stać się krytyczną częścią rozwiązania.

Poniżej przedstawiono obszary, które należy wziąć pod uwagę podczas planowania wydajności:

  • Usługa wystawiania Zweryfikowany identyfikator Microsoft Entra jest wdrażana w regionach Europa Zachodnia, Europa Północna, Zachodnie stany USA 2, Zachodnio-środkowe stany USA, Australia i Japonia. Jeśli Twoja dzierżawa firmy Microsoft Entra znajduje się w UE, usługa Zweryfikowany identyfikator Microsoft Entra również znajduje się w UE.

  • Aby ograniczyć opóźnienie, wdróż witrynę internetową frontonu wystawiania i magazyn kluczy w regionie wymienionym powyżej.

Model oparty na przepływności:

  • Usługa Wystawca podlega limitom usługi Azure Key Vault.

  • W przypadku usługi Azure Key Vault istnieją trzy operacje podpisywania związane z każdym wystawianiem VC:

    • Jeden do żądania wystawiania z witryny sieci Web

    • Jeden dla utworzonego vc

    • Jeden dla pobierania kontraktu

  • Nie można kontrolować ograniczania przepustowości; zalecamy jednak zapoznanie się ze wskazówkami dotyczącymi ograniczania przepustowości usługi Azure Key Vault.

  • Jeśli planujesz duże wdrożenie i dołączanie maszyn wirtualnych, rozważ tworzenie partii vc, aby upewnić się, że nie przekraczasz limitów.

W ramach planu wydajności określ, co monitorujesz, aby lepiej zrozumieć wydajność rozwiązania. Oprócz monitorowania witryny internetowej na poziomie aplikacji należy wziąć pod uwagę następujące kwestie, ponieważ definiujesz strategię monitorowania wystawiania VC:

W celu zapewnienia skalowalności rozważ zaimplementowanie metryk dla następujących elementów:

  • Zdefiniuj fazy logiczne procesu wystawiania. Na przykład:

  • Początkowe żądanie

  • Obsługa kodu QR lub linku bezpośredniego

  • Wyszukiwanie atrybutów

  • Wywołania usługi wystawiania Zweryfikowany identyfikator Microsoft Entra

  • Wystawione poświadczenia

  • Zdefiniuj metryki na podstawie faz:

    • Łączna liczba żądań (wolumin)

    • Żądania na jednostkę czasu (przepływność)

    • Czas spędzony (opóźnienie)

  • Monitorowanie usługi Azure Key Vault przy użyciu następującego linku:

  • Monitoruj składniki używane dla warstwy logiki biznesowej.

Planowanie niezawodności

Aby zaplanować niezawodność, zalecamy:

  • Po zdefiniowaniu celów dostępności i nadmiarowości skorzystaj z poniższych przewodników, aby dowiedzieć się, jak osiągnąć cele:

  • W przypadku warstwy frontonu i firmy rozwiązanie może manifestować się nieograniczoną liczbą sposobów. Podobnie jak w przypadku dowolnego rozwiązania, w przypadku zidentyfikowanych zależności upewnij się, że zależności są odporne i monitorowane.

Jeśli rzadkie zdarzenie, że usługa wystawiania Zweryfikowany identyfikator Microsoft Entra lub usługi Azure Key Vault staną się niedostępne, całe rozwiązanie stanie się niedostępne.

Planowanie zgodności

Twoja organizacja może mieć określone wymagania dotyczące zgodności związane z branżą, typem transakcji lub krajem/regionem operacji.

Miejsce przechowywania danych: usługa wystawiania Zweryfikowany identyfikator Microsoft Entra jest wdrażana w podzestawie regionów świadczenia usługi Azure. Usługa jest używana tylko dla funkcji obliczeniowych. Nie przechowujemy wartości weryfikowalnych poświadczeń w systemach firmy Microsoft. Jednak w ramach procesu wystawiania dane osobowe są wysyłane i używane podczas wydawania maszyn wirtualnych. Korzystanie z usługi VC nie powinno mieć wpływu na wymagania dotyczące rezydencji danych. Jeśli przechowujesz jakiekolwiek dane osobowe w ramach weryfikacji tożsamości, powinny być przechowywane w sposób i w regionie spełniającym wymagania dotyczące zgodności. Aby uzyskać wskazówki dotyczące platformy Azure, odwiedź witrynę internetową Microsoft Trust Center.

Odwoływanie poświadczeń: określ, czy organizacja musi odwołać poświadczenia. Na przykład administrator może wymagać odwołania poświadczeń, gdy pracownik opuści firmę. Aby uzyskać więcej informacji, zobacz Odwoływanie wcześniej wystawionych poświadczeń weryfikowalnych.

Wygasające poświadczenia: określ, jak wygasają poświadczenia. Jeśli na przykład wydasz vc jako dowód posiadania prawa jazdy, może wygaśnie po kilku latach. Inne komputery wirtualne mogą mieć krótszą ważność, aby upewnić się, że użytkownicy wracają okresowo w celu zaktualizowania ich vc.

Planowanie operacji

Podczas planowania operacji należy opracować schemat używany do rozwiązywania problemów, raportowania i rozróżniania różnych klientów, których obsługujesz. Ponadto jeśli zespół operacyjny jest odpowiedzialny za wykonywanie odwołania VC, należy zdefiniować ten proces. Każdy krok procesu powinien być skorelowany, aby można było określić, które wpisy dziennika mogą być skojarzone z każdym unikatowym żądaniem wystawiania. W przypadku inspekcji zalecamy przechwycenie każdej próby wystawienia poświadczeń indywidualnie. Szczególnie:

  • Generowanie unikatowych identyfikatorów transakcji, które klienci i inżynierowie pomocy technicznej mogą odwoływać się do określonych potrzeb.

  • Opracowanie mechanizmu korelowania dzienników transakcji usługi Azure Key Vault z identyfikatorami transakcji części wystawiania rozwiązania.

  • Jeśli jesteś usługą weryfikacji tożsamości wystawiającą maszyny wirtualne w imieniu wielu klientów, monitoruj i ograniczaj je według identyfikatora klienta lub umowy na potrzeby raportowania i rozliczeń dla klientów.

  • Jeśli jesteś usługą weryfikacji tożsamości wystawiającą maszyny wirtualne w imieniu wielu klientów, użyj identyfikatora klienta lub kontraktu na potrzeby raportowania i rozliczeń, monitorowania i ograniczania ryzyka związanego z klientem.

Planowanie pod kątem zabezpieczeń

W ramach zagadnień projektowych dotyczących zabezpieczeń zalecamy następujące elementy:

  • W przypadku zarządzania kluczami:

    • Utwórz dedykowaną usługę Key Vault na potrzeby wystawiania vc. Ogranicz uprawnienia usługi Azure Key Vault do usługi wystawiania Zweryfikowany identyfikator Microsoft Entra i jednostki usługi internetowej frontonu usługi wystawiania.

    • Traktuj usługę Azure Key Vault jako wysoce uprzywilejowany system — usługa Azure Key Vault wystawia poświadczenia klientom. Zalecamy, aby żadne tożsamości człowieka nie miały stałych uprawnień w usłudze Azure Key Vault. Administratorzy powinni mieć tylko dostęp just I time do usługi Key Vault. Aby uzyskać więcej najlepszych rozwiązań dotyczących użycia usługi Azure Key Vault, zobacz Punkt odniesienia zabezpieczeń platformy Azure dla usługi Key Vault.

  • W przypadku jednostki usługi reprezentującej witrynę internetową frontonu wystawiania:

    • Zdefiniuj dedykowaną jednostkę usługi w celu autoryzowania dostępu do usługi Azure Key Vault. Jeśli twoja witryna internetowa znajduje się na platformie Azure, zalecamy użycie tożsamości zarządzanej platformy Azure.

    • Traktuj jednostkę usługi reprezentującą witrynę internetową i użytkownika jako pojedynczą granicę zaufania. Chociaż istnieje możliwość utworzenia wielu witryn internetowych, istnieje tylko jeden klucz ustawiony dla rozwiązania wystawiania.

W przypadku rejestrowania i monitorowania zabezpieczeń zalecamy następujące elementy:

  • Włącz rejestrowanie i alerty usługi Azure Key Vault, aby śledzić operacje wystawiania poświadczeń, próby wyodrębniania kluczy, zmiany uprawnień oraz monitorować i wysyłać alerty dotyczące zmian konfiguracji. Więcej informacji można znaleźć w artykule How to enable Key Vault logging (Jak włączyć rejestrowanie usługi Key Vault).

  • Archiwizowanie dzienników w systemach zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takich jak Microsoft Sentinel na potrzeby długoterminowego przechowywania.

  • Ograniczanie ryzyka fałszowania przy użyciu następujących czynności

    • Weryfikacja DNS w celu ułatwienia klientom identyfikowania znakowania wystawców.

    • Nazwy domen, które mają znaczenie dla użytkowników końcowych.

    • Zaufane znakowanie rozpoznawane przez użytkownika końcowego.

  • Ograniczenie ryzyka wyczerpania zasobów rozproszonej odmowy usługi (DDOS) i magazynu Key Vault. Każde żądanie wyzwalające żądanie wystawiania VC generuje operacje podpisywania usługi Key Vault, które są naliczane w kierunku limitów usług. Zalecamy ochronę ruchu przez włączenie uwierzytelniania lub captcha przed wygenerowaniem żądań wystawiania.

Aby uzyskać wskazówki dotyczące zarządzania środowiskiem platformy Azure, zalecamy zapoznanie się z testem porównawczym zabezpieczeń w chmurze firmy Microsoft i zabezpieczaniem środowisk platformy Azure przy użyciu identyfikatora Entra firmy Microsoft. Te przewodniki zawierają najlepsze rozwiązania dotyczące zarządzania bazowymi zasobami platformy Azure, w tym usługą Azure Key Vault, usługą Azure Storage, witrynami internetowymi i innymi usługami i możliwościami powiązanymi z platformą Azure.

Uwagi dodatkowe

Po zakończeniu weryfikacji koncepcji zbierz wszystkie wygenerowane informacje i dokumentację oraz rozważ usunięcie konfiguracji wystawcy.

Aby uzyskać więcej informacji na temat implementacji i operacji usługi Key Vault, zobacz Najlepsze rozwiązania dotyczące korzystania z usługi Key Vault. Aby uzyskać więcej informacji na temat zabezpieczania środowisk platformy Azure za pomocą usługi Active Directory, zobacz Zabezpieczanie środowisk platformy Azure przy użyciu identyfikatora Entra firmy Microsoft.

Następne kroki

Przeczytaj omówienie architektury

Planowanie rozwiązania weryfikacji

Wprowadzenie do weryfikowalnych poświadczeń