Perguntas frequentes sobre identidade e credenciais digitais

P: Qual é o processo detalhado para um novo parceiro se integrar como uma parte confiável (RP)?

R: Siga o guia explicativo em: Escolha seu caminho.

P: Qual é a duração típica do processo de integração de RP?

R: Normalmente, a integração leva de 3 a 5 dias úteis.

P: Como podemos acompanhar o status da nossa inscrição de parte confiável (RP) após o envio?

R: Se você não receber uma resposta após 5 dias, entre em contato com nossa equipe de suporte em wallet-identity-rp-support@google.com.

P: Onde podemos encontrar o formulário de integração da parte confiável e a documentação para desenvolvedores oficial?

A:

• Formulário de integração:formulário de contato para parceiros de confiança de identidade da Carteira do Google
• Documentação para desenvolvedores:Visão geral da identidade digital

P: Como as informações que fornecemos (como nome e logotipo do produto) serão usadas na experiência do produto?

R: O nome e o logotipo do produto são exibidos na tela de permissão voltada ao usuário para ajudar a identificar qual parte confiável está solicitando o documento de identificação digital. URLs e links de políticas também podem aparecer na experiência do produto.

P: Precisamos assinar os Termos de Serviço se planejamos usar apenas o ambiente de sandbox para desenvolvimento e testes?

R: Não, aceitar os Termos de Serviço não é uma etapa obrigatória para o teste.

P: Onde podemos encontrar uma implementação de referência, um exemplo de código ou um aplicativo de demonstração para começar?

A:

• Repositório do GitHub:implementação de referência de identidade.
• Site de teste:verifier.multipaz.org

P: O que é o Verifier Registrar e como ele funciona?

R: O Verifier Registrar atua como uma autoridade certificadora que integra clientes downstream (RPs finais). A RP final não interage diretamente com a Carteira do Google.

P: Qual é o processo de integração específico para um Verifier Registrar e os clientes downstream dele?

A: Consulte as etapas em: Guia do Verificador Registrador.

P: Qual é a diferença em relação a uma integração direta com a parte confiável?

R: Os registradores de verificadores gerenciam a relação de confiança dos clientes e cuidam da integração com a Carteira do Google em nome deles, enquanto as RPs diretas gerenciam a própria configuração com o Google.

P: No Verifier Registrar, quem é incluído na lista de permissões na configuração do Google: o Verifier Registrar, a RP final ou ambos?

R: O Google inclui na lista de permissões o certificado de CA raiz do registrador do verificador. Em seguida, o Verifier Registrar emite novos certificados de folha para cada RP final downstream.

P: Como os dados fluem entre a parte confiável final, o registro do verificador e a Carteira do Google?

A: O registrador do verificador envia a solicitação de API à Carteira do Google para a parte confiável final. A Carteira do Google retorna os dados de credenciais criptografados para o Verifier Registrar, que os processa e envia o sinal final para o RP final.

P: Para soluções de marca branca, é necessário mostrar o nome do registrador do verificador no fluxo de consentimento do usuário ou pode ser apenas o nome da parte confiável final?

R: Não. O registrador do verificador pode optar por não exibir os detalhes.

P: Quais são os tipos de chave e curvas permitidos para as ACs raiz e os certificados de RP?

R: Os certificados precisam ser gerados usando P-256 / ECDSA.

P: Podemos usar certificados de signatário intermediários entre nossa CA raiz e os certificados de folha da parte confiável?

R: Sim. É possível armazenar com segurança um certificado raiz de longa duração (por exemplo, em um HSM) para assinar com pouca frequência certificados intermediários operacionais. Esses certificados intermediários podem ser usados para assinar certificados de folha de RP final, o que facilita a rotação em caso de violação sem afetar a raiz.

P: Qual é o ciclo de vida necessário para os certificados?

R: Um ciclo de vida de 10 anos é perfeitamente aceitável para um certificado de CA raiz. Os certificados de folha de RP final geralmente devem seguir um cronograma de renovação de cerca de 1 ano para garantir que possam ser alternados de forma eficiente se surgirem problemas.

P: Precisamos gerenciar um certificado de folha separado para cada cliente de parte confiável (RP, na sigla em inglês)?

R: Sim. No período de lançamento inicial, os agregadores precisam gerenciar certificados separados para cada RP downstream. Isso permite configurações de exibição por RP e rastreamento preciso de abusos. Embora isso adicione sobrecarga operacional em escala, pretendemos revisar possíveis alternativas (como o uso de hashes de metadados de RP) após o lançamento inicial.

P: Os parceiros podem ter vários certificados ativos ao mesmo tempo?

R: Sim, a configuração aceita qualquer número de certificados ativos por RP ou agregador, o que é útil para parceiros que operam com vários nomes comerciais.

P: Como o nome distinto (assunto) deve ser formatado?

R: O nome diferenciado precisa ser globalmente exclusivo por parceiro. Ele serve como um identificador estático que o Google usa para monitorar as solicitações recebidas de parceiros e garantir a confiança do ecossistema.

P: Como funciona a vinculação de domínio? As origens precisam ser incorporadas ao certificado?

R: Os domínios não precisam ser incorporados diretamente no certificado. Em vez disso, a verificação de domínio é realizada usando o parâmetro de origens esperadas na chamada de API. Além disso, vários domínios podem ser associados a um único certificado. Para solicitações não assinadas, a vinculação é executada usando o nome do domínio ou do pacote do app com uma impressão digital.

P: Os detalhes do agregador podem ser omitidos da interface de verificação para uma experiência de marca branca?

Sim, as informações agregadas (como nome, logotipo, URL e Política de Privacidade) são totalmente opcionais nos metadados do verificador. Isso permite uma solução totalmente white-label, em que apenas os detalhes da parte confiável final são mostrados ao usuário.

P: O que precisamos fornecer para começar os testes no ambiente de sandbox?

R: Do ponto de vista técnico, você só precisa fornecer o certificado raiz do Sandbox. O sandbox foi projetado para espelhar de forma idêntica o ambiente de produção.

P: Qual é a diferença no processo de integração para registradores de verificadores (agregadores) em comparação com as partes confiáveis diretas?

R: Os agregadores passam por um processo um pouco diferente. Depois de executar os Termos de Serviço específicos do Verifier Registrar, o processo é dividido em duas partes: um formulário principal para estabelecer seu status como Verifier Registrar, seguido por um formulário simplificado necessário para cada RP que você integrar. Cada envio de RP geralmente requer uma gravação de vídeo da integração, e o processo de análise geralmente leva de 2 a 3 dias úteis.

P: Podemos integrar clientes que pretendem atuar como intermediários ou revender serviços de verificação para outras entidades?

R: Não. O modelo e a preferência atuais do Google são trabalhar diretamente com os registradores de verificadores (agregadores) e as partes confiáveis finais diretas, em vez de oferecer suporte a modelos de revendedores ou intermediários aninhados.

P: Qual é o protocolo subjacente para solicitações? Quais versões são compatíveis?

R: O protocolo principal é o OpenID for Verifiable Presentations (OpenID4VP) versão 1.0.

P: Quais anexos da ISO 18013-7 (por exemplo, anexos B, C, D) o Google aceita para a apresentação de mDLs?

R: O Google é compatível com o Anexo D [atualmente em rascunho] (OpenID4VP usando a API DC).

P: Como estruturar corretamente uma solicitação de API para pedir várias credenciais em uma única apresentação do usuário?

R: Os dois tipos de credencial precisam ser solicitados em um único objeto de consulta dcql na mesma solicitação JSON.

P: A API permite solicitar uma credencial genérica sem listar todos os tipos possíveis?

R: Não.

P: Como a API lida com a confirmação de idade? Podemos solicitar a data de nascimento exata ou apenas um indicador de "maior de X anos"?

R: Ambos são aceitos. É possível solicitar birth_date, age_in_years ou um indicador "acima de X" que preserva a privacidade. As provas de conhecimento zero (ZKPs, na sigla em inglês) também podem ser usadas para um sinal de verdadeiro/falso.

P: Quais são os requisitos para nossa infraestrutura de PKI?

R: As partes confiáveis precisam de uma PKI para assinar solicitações. Os registradores de verificação atuam como a própria CA.

P: Podemos usar nossos próprios certificados ou precisamos de um novo assinado pelo Google?

R: As partes confiáveis precisam de um novo certificado assinado pelo Google ou por um registrador de verificadores. Para registradores de verificadores, o Google vai confiar no seu certificado raiz se você seguir as etapas de "Estabelecimento de confiança" na documentação.

P: Qual é a estratégia de integração recomendada para a Web em comparação com o app Android?

R: Toda a solicitação precisa ser gerada do lado do servidor. No Android, use a API Credman. Na Web, use a API Digital Credentials (DC).

P: Quais ferramentas de depuração, geração de registros e observabilidade estão disponíveis para desenvolvedores?

R: Os parceiros podem usar o alias de suporte wallet-identity-rp-support@google.com. Não são fornecidas ferramentas específicas de geração de registros ou observabilidade.

P: Quais documentos de identificação digitais, emissores e credenciais são aceitos por país e região?

R: Encontre as regiões com disponibilidade aqui: Emissores e certificados aceitos.

P: Quando vocês planejam aceitar credenciais de novos países ou regiões?

R: Estamos adicionando novas regiões. Confira as atualizações na página de emissores aceitos.

P: Quando uma credencial é atualizada pelo emissor, o usuário final recebe uma notificação?

R: Sim, o usuário é notificado, e a atualização é aplicada automaticamente.

P: Como podemos acessar um ambiente de sandbox para testar o fluxo completo de ponta a ponta?

R: O sandbox está aberto em: Modo sandbox.

P: Qual é o processo para que parceiros que não estão em uma região de lançamento oficial sejam adicionados à lista de permissões para testes?

R: Envie os IDs do Gmail das carteiras de teste para wallet-identity-rp-support@google.com.

P: Qual é o processo para ativar um site ou app de teste para fins de demonstração, permitindo que qualquer pessoa com uma credencial de produção o apresente?

R: Os parceiros precisam concluir a integração padrão do RP, incluindo uma demonstração em vídeo do sandbox.

P: Qual é a experiência do usuário se ele não tiver um documento de identificação digital ou o app Carteira do Google instalado ao iniciar um fluxo de verificação?

Os usuários que não tiverem o app serão direcionados à Google Play Store. Quem não tiver um ID poderá criar um no fluxo usando a interface de meia tela.

P: Podemos detectar de forma programática se um usuário tem um documento de identificação digital na Carteira antes de mostrar a opção de verificação?

R: Não, a API precisa ser invocada pelo usuário para proteger a privacidade.

P: Podemos exigir que o usuário desbloqueie o dispositivo com biometria antes de apresentar uma credencial?

R: A autenticação do usuário (biometria, PIN ou padrão) é obrigatória por padrão e não pode ser desativada.

P: É possível personalizar a ordem dos atributos solicitados na tela de consentimento do usuário?

R: Não, a Carteira do Google os reordena em ordem alfabética.

P: Nosso caso de uso envolve o compartilhamento de dados do usuário com terceiros. Isso é permitido pelos Termos de Serviço?

R: Sim, restrições podem ser aplicadas. Consulte nossos Termos de Serviço para mais detalhes.

P: Qual documentação está disponível sobre a segurança, confiabilidade e acessibilidade das soluções de identidade digital para fins de compliance?

R: Os parceiros podem consultar as análises de segurança da Trail of Bits.

P: Quais são os recursos das provas de conhecimento zero (ZKP, na sigla em inglês) para a confirmação de idade que preserva a privacidade?

R: A prova de conhecimento zero (ZKP, na sigla em inglês) é um método criptográfico que permite que um indivíduo (o provador) prove a um verificador que possui uma determinada informação de identidade ou atende a um critério específico (por exemplo, tem mais de 18 anos, possui uma credencial válida) sem revelar os dados subjacentes reais.

P: Como as diferentes versões dos circuitos ZK são processadas?

A: As partes confiáveis precisam implementar serviços de verificação de ZK para solicitar os circuitos mais recentes disponíveis.

P: Como funciona o compartilhamento e o gerenciamento de credenciais em vários dispositivos, como um smartphone e um wearable?

R: As credenciais são provisionadas para um único dispositivo e não podem ser compartilhadas.

P: Como o Google lida com a revogação de um passe de identificação se um passaporte for revogado?

R: Os usuários podem excluir cartões nas configurações da Conta do Google. Dispositivos perdidos podem ser denunciados para revogar as credenciais.

P: Como é feita a revogação da mDL? É em tempo real?

R: Ele pode ser acionado pelo usuário ou enviado pelo emissor (DMV). É em tempo real se o dispositivo estiver on-line. Caso contrário, os objetos de segurança de curta duração (MSOs, na sigla em inglês) vão expirar.

P: Qual é a política de rotação de chaves para as partes confiáveis?

R: Recomendamos a rotação anual.

P: Qual é a versão mínima do Android compatível com a API Digital Credentials?

R: Android 9 (nível 28 da API) e versões mais recentes.

P: Qual é a versão mínima do Chrome que oferece suporte à API Digital Credentials?

R: Chrome versão 128 e mais recentes.

P: Quais navegadores são compatíveis com a API Digital Credentials?

R: Confira os detalhes sobre a compatibilidade com navegadores aqui: https://digitalcredentials.dev/ecosystem-support

P: Quais usuários poderão adicionar um documento de identificação quando um novo país for lançado?

O acesso é baseado na configuração de país do usuário na Google Play Store.

P: A API Digital Credentials funciona com o iOS?

R: Sim, a API funciona com navegadores compatíveis, como o Safari. No entanto, o OpenID4VP não é compatível com a Apple.