Share via

Vanliga frågor och svar (FAQ)

  • Artikel

Den här sidan innehåller vanliga frågor om verifierbara autentiseringsuppgifter och decentraliserad identitet. Frågor ordnas i följande avsnitt.

Grunderna

Vad är en DID?

Decentraliserade identifierare (DID) är unika identifierare som kan användas för att skydda åtkomsten till resurser, signera och verifiera autentiseringsuppgifter och underlätta utbyte av programdata. Till skillnad från traditionella användarnamn och e-postadresser, entiteter och ägande och kontroll av did själva (oavsett om det är en person, enhet eller företag). DID:er finns oberoende av någon extern organisation eller betrodd mellanhand. Specifikationen för den decentraliserade identifieraren i W3C förklarar DID:er i detalj.

Varför behöver vi en DID?

Digitalt förtroende kräver i grunden att deltagarna äger och kontrollerar sina identiteter, och identiteten börjar vid identifieraren. I en tid av dagliga, storskaliga systemöverträdelser och attacker på centraliserade identifierarhonungar blir decentralisering av identitet ett kritiskt säkerhetsbehov för konsumenter och företag. Individer som äger och kontrollerar sina identiteter kan utbyta verifierbara data och bevis. En distribuerad miljö för autentiseringsuppgifter möjliggör automatisering av många affärsprocesser som för närvarande är manuella och arbetsintensiva.

Vad är en verifierbar autentiseringsuppgift?

Autentiseringsuppgifter är en del av vårt dagliga liv. Körkort används för att hävda att vi kan köra ett motorfordon. Universitetsexamina kan användas för att hävda att vår utbildningsnivå och myndighetsutfärdade pass gör det möjligt för oss att resa mellan länder och regioner. Verifierbara autentiseringsuppgifter ger en mekanism för att uttrycka den här typen av autentiseringsuppgifter på webben på ett sätt som är kryptografiskt säkert, med respekt för sekretess och maskinverifierbar. Specifikationen för verifierbara autentiseringsuppgifter i W3C förklarar verifierbara autentiseringsuppgifter i detalj.

Konceptuella frågor

Vad händer när en användare förlorar sin telefon? Kan de återställa sin identitet?

Det finns flera sätt att erbjuda en återställningsmekanism för användare, var och en med sina egna kompromisser. Microsoft utvärderar för närvarande alternativ och utformar metoder för återställning som ger bekvämlighet och säkerhet samtidigt som användarens integritet och självsuveränitet respekteras.

Hur kan en användare lita på en begäran från en utfärdare eller kontrollant? Hur vet de att en DID är den verkliga DID för en organisation?

Vi implementerar den decentraliserade identitetsstiftelsens välkända DID-konfigurationsspecifikation för att ansluta en DID till ett mycket känt befintligt system, domännamn. Varje DID som skapades med hjälp av Microsoft Entra – verifierat ID har möjlighet att inkludera ett rotdomännamn som är kodat i DID-dokumentet. Följ artikeln Link your Domain to your Distributed Identifier (Länka domänen till din distribuerade identifierare ) om du vill veta mer.

Vilka är licensieringskraven?

Det finns inga särskilda licenskrav för att utfärda verifierbara autentiseringsuppgifter.

Hur gör jag för att återställa Microsoft Entra – verifierat ID-tjänsten?

Återställning kräver att du avregistrerar dig och väljer tillbaka till Microsoft Entra – verifierat ID-tjänsten. Din befintliga konfiguration av verifierbara autentiseringsuppgifter återställs och klientorganisationen får en ny DID som ska användas under utfärdande och presentation.

  1. Följ avanmälningsinstruktionerna.
  2. Gå Microsoft Entra – verifierat ID distributionsstegen för att konfigurera om tjänsten.
    1. Om du konfigurerar verifierat ID manuellt väljer du en plats där Azure Key Vault ska finnas i samma eller närmaste region. På så sätt undviker du problem med prestanda och svarstider.
  3. Slutför konfigurationen av tjänsten för verifierbara autentiseringsuppgifter. Du måste återskapa dina autentiseringsuppgifter.
    1. Om din klientorganisation behöver konfigureras som utfärdare rekommenderar vi att ditt lagringskonto finns i den europeiska regionen som din verifierbara tjänst för autentiseringsuppgifter.
    2. Du måste också utfärda nya autentiseringsuppgifter eftersom din klientorganisation nu har en ny DID.

Hur kan jag kontrollera min Microsoft Entra-klientorganisations region?

  1. I Azure-portalen går du till Microsoft Entra-ID för den prenumeration du använder för din Microsoft Entra – verifierat ID distribution.
  2. Under Hantera väljer du Egenskaper inställningar ta bort och avregistrera
  3. Se värdet för Land eller Region. Om värdet är ett land eller en region i Europa konfigureras din Microsoft Entra – verifierat ID-tjänst i Europa.

Stöder Microsoft Entra – verifierat ID ION som did-metod?

Verifierat ID stödde metoden DID:ION i förhandsversionen fram till december 2023, varefter den upphörde.

Hur gör jag för att flytta till did:web från did:ion?

Om du vill flytta till did:web från did:ionkan du följa de här stegen via administratörs-API:et. För att ändra utfärdare krävs att alla autentiseringsuppgifter utfärdas på nytt:

Exportera befintliga definitioner av did:ion-autentiseringsuppgifter

  1. För utfärdaren did:ion använder du portalenför att kopiera alla visnings- och regeldefinitioner för befintliga autentiseringsuppgifter.
  2. Om du har fler än en utfärdare måste du använda administratörs-API:erna om utfärdaren did:ion inte är standardutfärdare. I klientorganisationen Verifierat ID ansluter du med hjälp av administratörs-API:et och listar myndigheterna för att hämta utfärdar-ID:t för utfärdaren did:ion . Använd sedan API:et för listkontrakt för att exportera dem och spara resultatet i en fil så att du kan återskapa dem.

Skapa ny did:web authority

  1. Skapa den nya did:web utfärdaren med hjälp av det registrerade API:et. Om din klientorganisation bara har en did:ion-utfärdare kan du också utföra en tjänstavvikelse följt av en anmälningsåtgärd för att starta om med konfigurationer för verifierat ID. I det här fallet kan du välja mellan Snabb och Manuell konfiguration.
  2. Om du konfigurerar en did:web-utfärdare med hjälp av administratörs-API måste du anropa generera DID-dokument för att generera dokumentet och anropa generera välkända dokument och sedan ladda upp JSON-filer till respektive välkända sökväg.

Återskapa definitioner för autentiseringsuppgifter

När du har skapat den nya did:web utfärdaren måste du återskapa definitionerna för autentiseringsuppgifter. Du kan antingen göra det via portalenom du valde bort och återregistrerade dig, eller så måste du använda API:et för att skapa kontrakt för att återskapa dem.

Uppdatera befintliga program

  1. Uppdatera något av dina befintliga program (utfärdare/kontrollantappar) för att använda den nya did:web authority. För utfärdandeappar uppdaterar du även URL:en för autentiseringsmanifestet.
  2. Testutfärdning och verifieringsflöden från den nya did:web-utfärdaren. När testerna har slutförts går du vidare till nästa steg för borttagning av did:ion-utfärdare.

Ta bort did:ion authority

Om du inte valde bort och registrerade dig igen måste du ta bort den gamla did:ion utfärdaren. Använd API:et för att ta bort utfärdaren did:ion.

Ja, när du har konfigurerat om tjänsten har din klientorganisation en ny DID-användning för att utfärda och verifiera verifierbara autentiseringsuppgifter. Du måste associera din nya DID med din domän.

Går det att begära att Microsoft hämtar "gamla DID:er"?

Nej, i det här läget går det inte att behålla klientorganisationens DID när du har valt bort tjänsten.

Jag kan inte använda ngrok, vad gör jag?

Självstudierna för att distribuera och köra exemplen beskriver användningen av ngrok verktyget som en programproxy. Det här verktyget blockeras ibland av IT-administratörer från att användas i företagsnätverk. Ett alternativ är att distribuera exemplet till Azure App Service och köra det i molnet. Följande länkar hjälper dig att distribuera respektive exempel till Azure App Service. Prisnivån Kostnadsfri räcker för att vara värd för exemplet. För varje självstudie måste du börja med att först skapa Azure App Service-instansen och sedan hoppa över att skapa appen eftersom du redan har en app och sedan fortsätta självstudien med att distribuera den.

Oavsett vilket språk i exemplet du använder används Värdnamnet https://something.azurewebsites.net för Azure AppService som offentlig slutpunkt. Du behöver inte konfigurera något extra för att det ska fungera. Om du gör ändringar i koden eller konfigurationen måste du distribuera om exemplet till Azure AppServices. Felsökning/felsökning är inte lika enkelt som att köra exemplet på den lokala datorn, där spårningar till konsolfönstret visar fel, men du kan uppnå nästan samma sak med hjälp av Log Stream.

Nästa steg