Compartilhar via

Perguntas Frequentes (FAQ)

  • Artigo

Esta página contém perguntas frequentes sobre as Credenciais Verificáveis e a Identidade Descentralizada. As perguntas estão organizadas nas seções a seguir.

Noções básicas

O que é um DID?

Identificadores descentralizados (DIDs) são identificadores exclusivos usados para proteger o acesso a recursos, assinar e verificar credenciais e facilitar a troca de dados entre aplicativos. Ao contrário dos nomes de usuário e endereços de email tradicionais, as entidades possuem e controlam os próprios DIDs (seja uma pessoa, um dispositivo ou uma empresa). Os DIDs existem independentemente de qualquer organização externa ou intermediário confiável. A especificação do Identificador Descentralizado do W3C explica os DIDs mais detalhadamente.

Por que precisamos de um DID?

A confiança digital exige fundamentalmente que os participantes controlem suas identidades, e a identidade começa no identificador. Em uma era de violações e ataques diários do sistema em larga escala, em honeypots de identificador centralizado, a identidade descentralizada está se tornando uma necessidade de segurança crítica para consumidores e empresas. Os indivíduos que têm e controlam suas identidades são capazes de trocar dados verificáveis e provas. Um ambiente de credenciais distribuídas permite a automação de muitos processos de negócios que atualmente são manuais e trabalhosos.

O que é uma Credencial Verificável?

As credenciais fazem parte do nosso cotidiano. As carteiras de motorista são usadas para afirmar que somos capazes de operar um veículo motorizado. Os diplomas universitários podem ser usados para afirmar nosso nível de educação e os passaportes emitidos pelo governo nos permitem viajar entre países e regiões. As Credenciais Verificáveis fornecem um mecanismo para expressar esses tipos de credenciais na Web de maneira criptograficamente segura, com privacidade e verificável pelo computador. A especificação das Credenciais Verificáveis do W3C explica as credenciais verificáveis mais detalhadamente.

Perguntas conceituais

O que acontece quando um usuário perde seu celular? Eles podem recuperar sua identidade?

Há várias maneiras de oferecer um mecanismo de recuperação aos usuários, cada um possui suas próprias compensações. Atualmente, a Microsoft está avaliando opções e criando abordagens de recuperação que ofereçam conveniência e segurança, respeitando a privacidade e a auto-soberania do usuário.

Como um usuário pode confiar em uma solicitação de um emissor ou verificador? Como eles podem saber que um DID é o verdadeiro DID de uma organização?

Implementamos a especificação de Configuração Conhecida do DID da Identity Descentralized Foundation a fim de conectar um DID com um sistema existente altamente conhecido de nomes de domínio. Cada DID criado usando a ID Verificada do Microsoft Entra tem a opção de incluir um nome de domínio raiz que é codificado no documento DID. Siga o artigo intitulado Vincular seu domínio ao seu identificador distribuído para saber mais sobre domínios vinculados.

Quais são as limitações de tamanho para uma credencial verificável na ID verificada?

  • Para solicitação de emissão - 1 MB
  • Foto na credencial verificável - 1 MB
  • Resultado do retorno de chamada 10 MB sem recibo

Quais são requisitos de licenciamento?

Não há requisitos especiais de licenciamento para emitir credenciais verificáveis.

Como redefinir o serviço Microsoft Entra Verified ID?

A redefinição requer que você recuse e aceite novamente o serviço de ID Verificada do Microsoft Entra. Sua configuração de credenciais verificáveis existente é redefinida e seu locatário obtém um novo DID para usar durante a emissão e a apresentação.

  1. Siga as instruções de desativação .
  2. Revise as etapas de implantação do Microsoft Entra Verified ID para reconfigurar o serviço.
    1. Se você estiver configurando manualmente a ID Verificada, escolha um local para que o Azure Key Vault esteja na mesma região ou mais próxima. Escolher a mesma região evita problemas de desempenho e latência.
  3. Conclua a configuração do serviço de credenciais verificáveis. Você precisa recriar suas credenciais.
    1. Você também precisa emitir novas credenciais porque seu locatário agora detém um novo DID.

Como verificar a região do locatário do Microsoft Entra?

  1. No portal do Azure, acesse o Microsoft Entra ID relativo à assinatura que você usa para a implantação do Microsoft Entra Verified ID.

  2. Em Gerenciar, selecione Propriedades.

    Captura de tela das configurações de exclusão e desativação.

  3. Confira o valor de País ou Região. Se o valor for um país ou uma região da Europa, o serviço de ID Verificada do Microsoft Entra está configurado na Europa.

A ID Verificada do Microsoft Entra dá suporte ao ION como seu método DID?

A ID Verificada dava suporte ao método DID:ION na versão prévia até dezembro de 2023, após a qual isso foi descontinuado.

Como fazer para mudar de did:ion para did:web?

Se você quiser mudar para did:web de did:ion, execute estas etapas por meio da API de Administração. Observe que a alteração da autoridade requer a reemissão de todas as credenciais:

Exportar definições de credencial did:ion existentes

  1. Para a autoridade did:ion, use o portal para copiar todas as definições de exibição e regras das credenciais existentes.
  2. Se você tiver mais de uma autoridade, precisará usar as APIs de Administrador se a autoridade did:ion não for a autoridade padrão. No locatário da ID Verificada, conecte-se usando a API de Administração, listar as autoridades, para obter a ID de autoridade para a autoridade did:ion. Em seguida, use a API de contratos de lista para exportá-los e salvar o resultado em um arquivo para que você possa recriá-los.

Criar uma nova autoridade did:web

  1. Usando a API de integração, crie a nova autoridade did:web. Como alternativa, se o locatário tiver apenas uma autoridade de did:ion, você também poderá recusar um serviço e seguir com uma operação de aceitação para reiniciar com as configurações de ID Verificada. Nesse caso, você pode escolher entre uma configuração Rápida e Manual.
  2. Se você estiver configurando uma autoridade did:web usando a API de Administrador, precisará chamar gerar documento DID para gerar seu documento e chamar gerar documento bem-conhecido e carregar arquivos JSON no respectivo caminho conhecido.

Recriar definições de credencial

Depois de criar sua nova did:web autoridade, você precisa recriar suas definições de credenciais. Faça isso por meio do portal se tiver recusado e feito a reintegração, ou se precisar usar a API criar contrato para recriá-los.

Atualizar aplicativos existentes

  1. Atualize qualquer um dos aplicativos existentes (aplicativos emissores/verificadores) para usar o novo did:web authority. Para aplicativos de emissão, atualize também a URL do manifesto de credencial.
  2. Testar fluxos de emissão e verificação da nova autoridade did:web. Após o êxito dos testes, prossiga para a próxima etapa para a exclusão da autoridade did:ion.

Excluir autoridade did:ion

Se você não recusou e fez a reintegração, precisará remover sua autoridade did:ion antiga. Use a API de exclusão de autoridade para excluir a autoridade did:ion.

Sim, depois de reconfigurar seu serviço, seu locatário tem um novo uso do DID para emitir e verificar credenciais verificáveis. Você precisa associar seu novo DID ao seu domínio.

É possível solicitar que a Microsoft recupere "DIDs antigos"?

Não, neste momento não é possível manter o DID do seu inquilino depois de ter optado por sair do serviço.

Não consigo usar o ngrok, o que eu faço?

Os tutoriais para implantar e executar as amostras descrevem o uso da ferramenta ngrok como um proxy de aplicativo. Às vezes, essa ferramenta é impedida pelos administradores de TI de serem usadas em redes corporativas. Uma alternativa é implantar a amostra no Serviço de Aplicativo do Azure e executá-la na nuvem. Os links a seguir ajudam você a implantar a respectiva amostra no Serviço de Aplicativo do Azure. O tipo de preço Gratuito será suficiente para hospedar o exemplo. Para cada tutorial, você precisa começar criando primeiro a instância do Serviço de Aplicativo do Azure, depois ignorar a criação do aplicativo, pois já tem um aplicativo e, em seguida, continuar o tutorial com a implantação dele.

Independentemente do idioma que você estiver usando, o nome do host do Azure AppService https://something.azurewebsites.net será usado como ponto de extremidade público. Você não precisa configurar algo extra para fazê-lo funcionar. Se você fizer alterações no código ou na configuração, precisará reimplantar a amostra para os Serviços de Aplicativos do Azure. A solução de problemas/depuração não é tão fácil quanto executar a amostra no seu computador local, no qual os rastreamentos para a janela do console mostram erros, mas você pode obter quase o mesmo usando o Fluxo de Log.

Proteção de rede para eventos de retorno de chamada

A API do Serviço de Solicitação usa retornos de chamada para uma URL fornecida pelo aplicativo de terceira parte confiável. Esse URL precisa ser acessível a partir do sistema de ID verificada para que os retornos de chamada sejam recebidos. Os retornos de chamada são provenientes da infraestrutura do Azure na mesma região que seu locatário do Microsoft Entra. Se você precisar fortalecer sua rede, terá duas opções.

  • Use as marcas de serviço de firewall do Azure AzureCloud.
  • Use o intervalo CIDR publicado para configurar seu firewall. Você precisa usar o AzureCloud.regiões que correspondem ao local em que seu locatário do Microsoft Entra está implantado para configurar seus firewalls para permitir a passagem do tráfego de retorno de chamada da API de Serviço de Solicitação. Por exemplo, se o locatário estiver na UE, você deverá escolher todos os intervalos CIDR do AzureCloud.northeurope, .westeurope, etc., à configuração de firewalls.

Próximas etapas