Perguntas frequentes sobre identidade e credenciais digitais

Esta página responde a perguntas frequentes sobre a integração com a Carteira do Google para identidade e credenciais digitais.

Integração e como começar

P: Qual é o processo detalhado para um novo parceiro fazer a integração como uma parte confiante (RP)?

R: Consulte as etapas em Aceitar documentos de identificação da Carteira on-line.

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

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

P: Como podemos acompanhar o status da nossa inscrição de Relying Party (RP) após o envio?

R: Se você não receber uma resposta após cinco 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 de RP e a documentação oficial para desenvolvedores?

A:

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

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

P: Precisamos assinar os Termos de Serviço se planejamos usar o ambiente de sandbox apenas 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:

Cartórios de verificação

P: O que é o registrador de verificação e como ele funciona?

R: O registrador de verificador atua como uma autoridade de certificação que integra clientes downstream (RPs finais). O RP de endpoint não interage diretamente com a Carteira do Google.

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

R: Consulte as etapas em: Guia do registrador de verificadores.

P: Qual é a diferença entre essa integração e uma integração direta de RP?

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. Já os RPs diretos gerenciam a própria configuração com o Google.

P: No registrador de verificador, quem é adicionado à lista de permissões na configuração do Google: o registrador de verificador, o RP final ou ambos?

O Google autoriza o certificado de CA raiz do registrador do verificador. Em seguida, o registrador do verificador emite novos certificados de folha para cada RP downstream.

P: Como os dados fluem entre o RP final, o registrador de verificador e a Carteira do Google?

R: O registrador do verificador envia a solicitação de API para a Carteira do Google para o RP final. A Carteira do Google retorna dados de credenciais criptografados para o registrador do verificador, que os processa e envia o sinal final para o RP final.

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

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

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

P: Podemos usar certificados de assinante intermediários entre nossa CA raiz e os certificados folha do RP?

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

P: Qual é o tempo de vida útil 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 seguem um cronograma de renovação de aproximadamente um ano para garantir que possam ser alternados de forma eficiente se surgirem problemas.

P: Precisamos gerenciar um certificado folha separado para cada cliente Relying Party (RP)?

R: Sim. No período inicial de lançamento, 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 aumente a sobrecarga operacional em grande escala, pretendemos analisar alternativas em potencial (como usar 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 distinto precisa ser exclusivo globalmente por parceiro. Ele serve como um identificador estático que o Google usa para monitorar as solicitações de parceiros recebidas e garantir a confiança do ecossistema.

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

R: Não é necessário incorporar os domínios diretamente no certificado. Em vez disso, a verificação de domínio é realizada usando o parâmetro "expectedOrigins" 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 pacote de domínio ou 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?

R: Sim, as informações do agregador (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 do RP final são mostrados ao usuário.

P: O que precisamos fornecer para começar a testar 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 o ambiente de produção de forma idêntica.

P: Como o processo de integração difere para registradores verificadores (agregadores) em comparação com RPs diretos?

R: Os agregadores passam por um processo ligeiramente modificado. Depois de executar os Termos de Serviço específicos do registrador de verificador, a entrada é dividida em duas partes: um formulário principal para estabelecer seu status como registrador de verificador, seguido de um formulário simplificado necessário para cada RP individual que você integrar. Cada envio de RP geralmente exige uma gravação em vídeo da integração, e o processo de revisão 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 registradores de verificadores (agregadores) e seus RP finais diretos, em vez de oferecer suporte a modelos aninhados de revendedores ou intermediários.

Integração técnica e API

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

R: O protocolo principal é o OpenID para apresentações verificáveis (OpenID4VP), versão 1.0.

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

R: O Google oferece suporte ao 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?

Os dois tipos de credenciais 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 "maior de X"?

R: Os dois são aceitos. Você pode 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 indicador verdadeiro/falso.

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

R: Os RPs precisam de uma PKI para assinar solicitações. Os registradores de verificadores atuam como uma CA própria.

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

R: Os RPs 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.

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 há ferramentas específicas de criação de registros ou observabilidade.

Credenciais e dados

P: Quais IDs digitais, emissores e credenciais são aceitos por país e região?

R: Confira as regiões compatíveis aqui: Emissores e certificados compatíveis.

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

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

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

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

P: Quais dados de credenciais, se houver, o Google armazena nos servidores, especialmente no contexto do GDPR?

R: O Google não salva dados relacionados a credenciais nos servidores. Eles são armazenados localmente e com segurança no dispositivo do usuário.

Testes e ambientes

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 lançada oficialmente 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 da sandbox.

Experiência do usuário (UX)

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 têm o app são direcionados à Google Play Store. Quem não tem um ID pode criar um no fluxo usando a interface de meia tela.

P: Podemos detectar por programação 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 uma biometria antes de apresentar uma credencial?

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

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

Segurança e conformidade

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

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

P: Qual documentação está disponível sobre a segurança, a confiabilidade e a 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.

Recursos avançados e roteiro

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

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 ele possui uma determinada informação de identidade ou atende a um critério específico (por exemplo, tem mais de 18 anos, possui uma qualificação válida) sem revelar os dados reais.

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

R: Os RPs precisam implementar serviços de verificação 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.

Outros

P: Como o Google lida com revogações de passe de identificação se um passaporte é 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). Ele é em tempo real se o dispositivo estiver on-line. Caso contrário, os objetos de segurança de curta duração (MSOs) vão expirar.

P: Qual é a política de rotação de chaves para RPs?

R: Recomendamos uma rotação anual.

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

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 de suporte a 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.