Visão geral da arquitetura do Microsoft Entra Verified ID

É importante planejar sua solução de credenciais verificáveis para que, além de emitir e/ou validar credenciais, você tenha uma visão completa dos impactos arquitetônicos e comerciais de sua solução. Se ainda não os analisou, recomendamos que reveja a Introdução ao Microsoft Entra Verified ID e as FAQs e, em seguida, conclua o tutorial de Introdução .

Esta visão geral da arquitetura apresenta os recursos e componentes do serviço Microsoft Entra Verified ID. Para obter informações mais detalhadas sobre emissão e validação, consulte

• Planeie a sua solução de emissão

• Planeie a sua solução de verificação

Abordagens à identidade

Hoje, a maioria das organizações usa sistemas de identidade centralizados para fornecer credenciais aos funcionários. Eles também usam vários métodos para trazer clientes, parceiros, fornecedores e partes confiáveis para os limites de confiança da organização. Esses métodos incluem federação, criação e gerenciamento de contas de convidado com sistemas como o Microsoft Entra B2B e criação de relações de confiança explícitas com partes confiáveis. A maioria das relações comerciais tem uma componente digital, pelo que permitir alguma forma de confiança entre organizações requer um esforço significativo.

Sistemas de identidade centralizados

As abordagens centralizadas ainda funcionam bem em muitos casos, como quando aplicativos, serviços e dispositivos dependem dos mecanismos de confiança usados dentro de um domínio ou limite de confiança.

Em sistemas de identidade centralizados, o provedor de identidade (IDP) controla o ciclo de vida e o uso das credenciais.

No entanto, há cenários em que o uso de uma arquitetura descentralizada com credenciais verificáveis pode fornecer valor aumentando cenários-chave, como

• Integração segura das identidades dos funcionários e de outras pessoas, incluindo cenários remotos.

• acesso a recursos dentro do limite de confiança organizacional com base em critérios específicos.

• acessar recursos fora do limite de confiança, como acessar recursos de parceiros, com uma credencial portátil emitida pela organização.

Sistemas de identidade descentralizados

Em sistemas de identidade descentralizados, o controle do ciclo de vida e do uso das credenciais é compartilhado entre o emissor, o titular e a terceira parte confiável que consome a credencial.

Considere o cenário no diagrama em que o Proseware, um site de comércio eletrônico, quer oferecer descontos corporativos aos funcionários da Woodgrove.

A terminologia para credenciais verificáveis (VCs) pode ser confusa se você não estiver familiarizado com VCs. As definições a seguir são da seção de terminologia do Modelo de Dados de Credenciais Verificáveis 1.0 . Depois de cada uma delas, relacionamo-las com entidades no diagrama anterior.

"Um emissor é um papel que uma entidade pode desempenhar afirmando declarações sobre um ou mais assuntos, criando uma credencial verificável a partir dessas declarações e transmitindo a credencial verificável a um titular."

• No diagrama anterior, Woodgrove é o emissor de credenciais verificáveis para seus funcionários.

"Um titular é um papel que uma entidade pode desempenhar possuindo uma ou mais credenciais verificáveis e gerando apresentações a partir delas. Um titular é normalmente, mas nem sempre, um sujeito das credenciais verificáveis que detém. Os titulares armazenam suas credenciais em repositórios de credenciais."

• No diagrama anterior, Alice é uma funcionária de Woodgrove. Eles obtiveram uma credencial verificável do emissor do Woodgrove, e é o detentor dessa credencial.

"Um verificador é uma função que uma entidade desempenha ao receber uma ou mais credenciais verificáveis, opcionalmente dentro de uma apresentação verificável para processamento. Outras especificações podem referir-se a este conceito como uma parte confiadora."

• No diagrama anterior, Proseware é um verificador de credenciais emitidas pelo Woodgrove.

"Uma credencial é um conjunto de uma ou mais declarações feitas por um emissor. Uma credencial verificável é uma credencial inviolável que tem autoria que pode ser verificada criptograficamente. Credenciais verificáveis podem ser usadas para criar apresentações verificáveis, que também podem ser verificadas criptograficamente. As reivindicações em uma credencial podem ser sobre diferentes assuntos."

"Um identificador descentralizado é um identificador portátil baseado em URI, também conhecido como DID, associado a uma entidade. Esses identificadores são frequentemente usados em uma credencial verificável e estão associados a sujeitos, emissores e verificadores."

"Um documento identificador descentralizado, também referido como um documento DID, é um documento que é acessível usando um registro de dados verificável e contém informações relacionadas a um identificador descentralizado específico, como o repositório associado e informações de chave pública."

• No cenário, tanto o emissor quanto o verificador têm um documento DID e um documento DID. O documento DID contém a chave pública e a lista de domínios Web DNS associados ao DID (também conhecidos como domínios vinculados).

• Woodgrove (emissor) assina VCs de seus funcionários com sua chave privada; da mesma forma, o Proseware (verificador) assina pedidos para apresentar um VC usando sua chave, que também está associada ao seu DID.

Um sistema de confiança é a base para estabelecer confiança entre sistemas descentralizados. Pode ser um livro-razão distribuído ou pode ser algo centralizado, como o DID Web.

"Um livro-razão distribuído é um sistema não centralizado para registrar eventos. Estes sistemas estabelecem confiança suficiente para que os participantes confiem nos dados registados por outros para tomarem decisões operacionais. Eles normalmente usam bancos de dados distribuídos onde diferentes nós usam um protocolo de consenso para confirmar a ordem de transações assinadas criptograficamente. A vinculação de transações assinadas digitalmente ao longo do tempo muitas vezes torna a história do livro-razão efetivamente imutável."

Combinando arquiteturas de identidade centralizadas e descentralizadas

Ao examinar uma solução de credenciais verificável, é útil entender como as arquiteturas de identidade descentralizadas podem ser combinadas com arquiteturas de identidade centralizadas para fornecer uma solução que reduza o risco e ofereça benefícios operacionais significativos.

A jornada do usuário

Esta visão geral da arquitetura acompanha a jornada de um candidato a emprego e funcionário, que se candidata e aceita emprego em uma organização. Em seguida, acompanha o funcionário e a organização através de mudanças onde credenciais verificáveis podem aumentar os processos centralizados.

Intervenientes nestes casos de utilização

• Alice, uma pessoa que se candidata e aceita emprego na Woodgrove, Inc.

• Woodgrove, Inc, uma empresa fictícia.

• Adatum, o parceiro fictício de verificação de identidade de Woodgrove.

• Proseware, a organização parceira fictícia de Woodgrove.

O Woodgrove usa arquiteturas de identidade centralizadas e descentralizadas.

Etapas na jornada do usuário

• Alice candidata-se, aceita e integra-se a uma posição na Woodgrove, Inc.

• Acesso a recursos digitais dentro do limite de confiança do Woodgrove.

• Acesso a recursos digitais fora do limite de confiança do Woodgrove sem estender os limites de confiança do Woodgrove ou dos parceiros.

À medida que a Woodgrove continua a operar seus negócios, ela deve gerenciar continuamente as identidades. Os casos de uso nesta orientação descrevem como Alice pode usar funções de autoatendimento para obter e manter seus identificadores e como o Woodgrove pode adicionar, modificar e encerrar relações entre empresas com requisitos de confiança variados.

Esses casos de uso demonstram como identidades centralizadas e identidades descentralizadas podem ser combinadas para fornecer uma estratégia e um ciclo de vida de identidade e confiança mais robustos e eficientes.

Jornada do usuário: Integração ao Woodgrove

Conscientização: Alice está interessada em trabalhar para a Woodgrove, Inc., e visita o site de carreira de Woodgrove.

Ativação: O site Woodgrove apresenta a Alice um método para provar sua identidade, solicitando-lhes um código QR ou um link profundo para visitar seu parceiro confiável de verificação de identidade, Adatum.

Solicitar e carregar: Adatum solicita prova de identidade de Alice. Alice tira uma selfie e uma foto da carta de condução e envia-as para o Adatum.

Emissão: Uma vez que Adatum verifica a identidade de Alice, Adatum emite a Alice uma credencial verificável (VC) atestando sua identidade.

Apresentação: Alice (titular e titular da credencial) pode então aceder ao portal de carreiras Woodgrove para concluir o processo de candidatura. Quando Alice usa o VC para acessar o portal, Woodgrove assume os papéis de verificador e a parte confiável, confiando no atestado da Adatum.

Distribuindo credenciais iniciais

Alice aceita emprego na Woodgrove. Como parte do processo de integração, uma conta do Microsoft Entra é criada para Alice usar dentro do limite de confiança do Woodgrove. O gerente de Alice deve descobrir como permitir que Alice, que trabalha remotamente, receba informações iniciais de login de forma segura. No passado, o departamento de TI poderia ter fornecido essas credenciais ao gerente, que as imprimia e entregava a Alice. A impressão das credenciais não funciona com funcionários remotos.

Os VCs podem agregar valor aos sistemas centralizados aumentando o processo de distribuição de credenciais. Em vez de precisar que o gerente forneça credenciais, Alice pode usar seu VC como prova de identidade para receber seu nome de usuário inicial e credenciais para acesso centralizado aos sistemas. Alice apresenta o comprovativo de identidade que adicionou à carteira como parte do processo de integração.

No caso de uso de integração, as funções de relacionamento de confiança são distribuídas entre o emissor, o verificador e o titular.

• O emitente é responsável pela validação das declarações que fazem parte do VC que emite. Adatum valida a identidade de Alice para emitir o VC. Neste caso, os VC são emitidos sem a consideração de um verificador ou de uma entidade utilizadora.

• O titular possui o CV e inicia a apresentação do CV para verificação. Só Alice pode apresentar os VCs que detém.

• O verificador aceita as declarações no VC de emissores em quem confia e valida o VC usando a capacidade de contabilidade descentralizada descrita no modelo de dados de credenciais verificáveis. Woodgrove confia nas alegações de Adatum sobre a identidade de Alice.

Ao combinar arquiteturas de identidade centralizadas e descentralizadas para integração, informações privilegiadas sobre Alice necessárias para a verificação de identidade, como um número de identificação do governo, não precisam ser armazenadas pelo Woodgrove, porque eles confiam que o VC de Alice emitido pelo parceiro de verificação de identidade (Adatum) confirma sua identidade. A duplicação de esforços é minimizada e uma abordagem programática e previsível para as tarefas iniciais de integração pode ser implementada.

Jornada do usuário: acessando recursos dentro do limite de confiança

Como funcionária, Alice está operando dentro do limite de confiança de Woodgrove. O Woodgrove atua como o provedor de identidade (IDP) e mantém o controle total da identidade e da configuração dos aplicativos que Alice usa para interagir dentro do limite de confiança do Woodgrove. Para usar recursos no limite de confiança do Microsoft Entra ID, Alice fornece potencialmente várias formas de prova de identificação para entrar no limite de confiança do Woodgrove e acessar os recursos dentro do ambiente de tecnologia do Woodgrove. Várias provas é um cenário típico que é bem servido usando uma arquitetura de identidade centralizada.

• O Woodgrove gerencia o limite de confiança e, usando boas práticas de segurança, fornece o nível menos privilegiado de acesso a Alice com base no trabalho executado. Para manter uma postura de segurança forte e, potencialmente, por motivos de conformidade, o Woodgrove também deve ser capaz de rastrear as permissões e o acesso dos funcionários aos recursos e deve ser capaz de revogar as permissões quando o emprego for encerrado.

• Alice usa apenas a credencial que o Woodgrove mantém para acessar os recursos do Woodgrove. Alice não precisa rastrear quando a credencial é usada, já que o Woodgrove está gerenciando a credencial e que só é usada com recursos do Woodgrove. A identidade só é válida dentro do limite de confiança do Woodgrove quando o acesso aos recursos do Woodgrove é necessário, então Alice não precisa possuir a credencial.

Usando VCs dentro do limite de confiança

Os funcionários individuais têm necessidades de identidade em mudança, e os VCs podem aumentar os sistemas centralizados para gerenciar essas mudanças.

• Enquanto empregada pelo Woodgrove, Alice pode precisar de acesso a recursos com base no cumprimento de requisitos específicos. Por exemplo, quando Alice conclui o treinamento de privacidade, ela pode receber um novo VC de funcionário com essa reivindicação, e esse VC pode ser usado para acessar recursos restritos.

• Os VCs podem ser usados dentro do limite de confiança para recuperação de conta. Por exemplo, se o funcionário perdeu o telefone e o computador, ele pode recuperar o acesso obtendo um novo VC do serviço de verificação de identidade, confiável pelo Woodgrove, e usar esse VC para obter novas credenciais.

Jornada do usuário: acessando recursos externos

Woodgrove negocia um desconto na compra de produtos com a Proseware. Todos os funcionários da Woodgrove são elegíveis para o desconto. Woodgrove quer fornecer a Alice uma maneira de acessar o site da Proseware e receber o desconto nos produtos comprados. Se o Woodgrove usa uma arquitetura de identidade centralizada, há duas abordagens para fornecer o desconto a Alice:

• Alice poderia fornecer informações pessoais para criar uma conta com Proseware, e então Proseware teria que verificar o emprego de Alice com Woodgrove.

• Woodgrove poderia expandir seu limite de confiança para incluir Proseware como uma parte confiável e Alice poderia usar o limite de confiança estendida para receber o desconto.

Com identificadores descentralizados, o Woodgrove pode fornecer a Alice uma credencial verificável (VC) que Alice pode usar para acessar o site da Proseware e outros recursos externos.

Ao fornecer Alice o VC, Woodgrove está atestando que Alice é uma funcionária. O Woodgrove é um emissor de VC confiável na solução de validação da Proseware. Essa confiança no processo de emissão do Woodgrove permite que a Proseware aceite eletronicamente o VC como prova de que Alice é uma funcionária do Woodgrove e forneça a Alice o desconto. Como parte da validação do VC Alice apresenta, Proseware verifica a validade do VC usando o sistema de confiança. Nesta solução:

• Woodgrove permite que Alice forneça prova de emprego Proseware sem que Woodgrove tenha que estender seus limites de confiança.

• A Proseware não precisa expandir seu limite de confiança para validar que Alice é uma funcionária da Woodgrove. Proseware pode usar o VC que Woodgrove fornece em vez disso. Como o limite de confiança não é expandido, gerenciar a relação de confiança é mais fácil, e o Proseware pode facilmente encerrar o relacionamento não aceitando mais os VCs.

• Alice não precisa fornecer informações pessoais da Proseware, como um e-mail. Alice mantém o VC numa aplicação de carteira num dispositivo pessoal. A única pessoa que pode usar o VC é Alice, e Alice deve iniciar o uso da credencial. Cada utilização do VC está a ser registada pela aplicação da carteira, pelo que Alice tem um registo de quando e onde o VC é utilizado.

Ao combinar arquiteturas de identidade centralizadas e descentralizadas para operar dentro e fora dos limites de confiança no Woodgrove, a complexidade e o risco podem ser reduzidos e os relacionamentos limitados se tornam mais fáceis de gerenciar.

Mudanças ao longo do tempo

O Woodgrove adiciona novas e encerra as relações comerciais atuais com outras organizações e precisa determinar quando arquiteturas de identidade centralizadas e descentralizadas são usadas.

Ao combinar arquiteturas de identidade centralizadas e descentralizadas, a responsabilidade e o esforço associados à identidade e à prova de identidade são distribuídos e o risco é reduzido. O usuário não corre o risco de liberar suas informações privadas com tanta frequência ou para tantos verificadores desconhecidos. Especificamente:

• Em arquiteturas de identidade centralizadas, o IDP emite credenciais e executa a verificação dessas credenciais emitidas. O IDP processa informações sobre todas as identidades. Ele os armazena em um diretório ou os recupera de um diretório. Opcionalmente, os IDPs podem aceitar tokens de segurança de outros sistemas IDP, como logins sociais ou parceiros comerciais. Para que uma terceira parte confiável use identidades no limite de confiança do IDP, elas devem ser configuradas para aceitar os tokens emitidos pelo IDP.

Como funcionam os sistemas de identidade descentralizados

Em arquiteturas de identidade descentralizadas, o emissor, o usuário e a terceira parte confiável (RP) têm um papel no estabelecimento e garantia da troca confiável contínua das credenciais uns dos outros. As chaves públicas dos DIDs dos atores são resolúveis através do sistema de confiança, que permite a validação da assinatura e, portanto, a confiança de qualquer artefato, incluindo uma credencial verificável. As partes confiáveis podem consumir credenciais verificáveis sem estabelecer relações de confiança com o emissor. Em vez disso, o emissor fornece ao titular uma credencial para apresentar como prova às partes confiadoras. Todas as mensagens entre atores são assinadas com o DID do ator; Os DIDs de emissores e verificadores também precisam possuir os domínios DNS que geraram as solicitações.

Por exemplo: Quando os detentores de VC precisam de aceder a um recurso, têm de apresentar o VC a essa entidade confiadora. Fazem-no utilizando uma aplicação de carteira para ler o pedido do RP para apresentar um VC. Como parte da leitura da solicitação, o aplicativo de carteira usa o DID do RP para encontrar as chaves públicas do RP usando o sistema de confiança, validando que a solicitação para apresentar o VC não foi adulterada. Para provar a propriedade do domínio, a carteira também verifica se o DID está sendo referenciado em um documento de metadados hospedado no domínio DNS do RP.

Fluxo 1: Emissão de credenciais verificáveis

Nesse fluxo, o titular da credencial interage com o emissor para solicitar uma credencial verificável, conforme ilustrado no diagrama a seguir

1. O titular inicia o fluxo usando um navegador ou aplicativo nativo para acessar o frontend da web do emissor. Lá, o site do emissor leva o usuário a coletar dados e executa a lógica específica do emissor para determinar se a credencial pode ser emitida e seu conteúdo.

2. O frontend da Web do emissor chama o serviço Microsoft Entra Verified ID para gerar uma solicitação de emissão de VC.

3. O frontend da Web renderiza um link para a solicitação como um código QR ou um deep link específico do dispositivo (dependendo do dispositivo).

4. O titular escaneia o código QR ou deep link da etapa 3 usando um aplicativo Wallet, como o Microsoft Authenticator

5. A carteira descarrega o pedido a partir do link. O pedido inclui:

   • DID do emitente. O DID do emissor é usado pelo aplicativo de carteira para resolver através do sistema de confiança para encontrar as chaves públicas e domínios vinculados.

   • URL com o manifesto VC, que especifica os requisitos do contrato para emitir o VC. O requisito do contrato pode incluir id_token, atributos autoatestados que devem ser fornecidos, ou a apresentação de outro VC.

   • Aspeto e funcionalidade do VC (URL do ficheiro do logótipo, cores, etc.).

6. A carteira valida os pedidos de emissão e processa os requisitos do contrato:

   1. Valida que a mensagem de solicitação de emissão é assinada pelas chaves do emissor encontradas no documento DID resolvido através do sistema de confiança. A validação da assinatura garante que a mensagem não foi adulterada.

   2. Valida que o emissor possui o domínio DNS referenciado no documento DID do emissor.

   3. Dependendo dos requisitos do contrato VC, a carteira pode exigir que o titular colete informações adicionais, por exemplo, solicitando atributos autoemitidos ou navegando por um fluxo OIDC para obter um id_token.

7. Envia os artefatos exigidos pelo contrato para o serviço de ID Verificada do Microsoft Entra. O serviço Microsoft Entra Verified ID devolve o VC, assinado com a chave DID do emissor e a carteira armazena o VC de forma segura.

Para obter informações detalhadas sobre como criar uma solução de emissão e considerações de arquitetura, consulte Planejar sua solução de emissão de ID Verificada do Microsoft Entra.

Fluxo 2: Apresentação de credenciais verificáveis

Neste fluxo, um titular interage com uma entidade confiadora (RP) para apresentar um VC como parte dos seus requisitos de autorização.

1. O titular inicia o fluxo usando um navegador ou aplicativo nativo para acessar o front-end da Web da terceira parte confiável.

2. O frontend da Web chama o serviço Microsoft Entra Verified ID para gerar uma solicitação de apresentação VC.

3. O frontend da Web renderiza um link para a solicitação como um código QR ou um deep link específico do dispositivo (dependendo do dispositivo).

4. O titular escaneia o código QR ou deep link da etapa 3 usando um aplicativo de carteira, como o Microsoft Authenticator

5. A carteira descarrega o pedido a partir do link. O pedido inclui:

   • Uma solicitação baseada em padrões para credenciais de um esquema ou tipo de credencial.

   • o DID do RP, que a carteira procura no sistema de confiança.

6. A carteira valida o pedido de apresentação e encontra VC(s) armazenado(s) que satisfazem o pedido. Com base nos VCs necessários, a carteira orienta o sujeito a selecionar e consentir o uso dos VCs.

   • O sujeito consente em partilhar o VC com o RP

   Em seguida, a carteira envia uma carga de resposta de apresentação para o serviço Microsoft Entra Verified ID assinado pelo assunto. Contém:

   • O(s) VC(s) do(s) sujeito(s) consentiu.

   • O assunto FEZ.

   • O RP DID como o "público" da carga útil.

7. O serviço Microsoft Entra Verified ID valida a resposta enviada pela carteira. Em alguns casos, o emissor do VC pode revogar o VC. Para se certificar de que o VC ainda é válido, o verificador tem de verificar com o emissor do VC. Isso depende de como o verificador pediu o VC na etapa 2.

8. Após a validação, o serviço Microsoft Entra Verified ID chama de volta o RP com o resultado.

Para obter informações detalhadas sobre como criar uma solução de validação e considerações de arquitetura, consulte Planejar sua solução de verificação de ID Verificada do Microsoft Entra.

Principais conclusões

Arquiteturas descentralizadas podem ser usadas para aprimorar soluções existentes e fornecer novos recursos.

Para atender às aspirações da Decentralized Identity Foundation (DIF) e das metas do W3C Design, os seguintes itens devem ser considerados ao criar uma solução de credencial verificável:

• Não existem pontos centrais de estabelecimento de confiança entre os intervenientes no sistema. Ou seja, os limites de confiança não são expandidos por meio da federação porque os atores confiam em VCs específicos.

  • O sistema de confiança permite a descoberta do identificador descentralizado (DID) de qualquer ator.

• A solução permite que os verificadores validem quaisquer credenciais verificáveis (VCs) de qualquer emissor.

• A solução não permite que o emissor controle a autorização do sujeito ou do verificador (terceira parte confiável).

• Os atores operam de forma dissociada, cada um capaz de completar as tarefas para os seus papéis.

  • Os emissores atendem a todas as solicitações de VC e não discriminam as solicitações atendidas.

  • Os sujeitos possuem o seu VC uma vez emitido e podem apresentar o seu VC a qualquer verificador.

  • Os verificadores podem validar qualquer VC de qualquer assunto ou emissor.

Próximos passos

Saiba mais sobre arquitetura para credenciais verificáveis

• Planeie a sua solução de emissão

• Planeie a sua solução de verificação

• Introdução ao Microsoft Entra Verified ID