Guia de integração do registrador de verificadores

Visão geral

Esta seção descreve o processo detalhado para registradores de verificadores fazerem a integração com o serviço de identidade da Carteira do Google.

Como registrador de verificador (por exemplo, uma empresa de IDV que faz a verificação em nome de outras entidades), você atua como sua própria autoridade certificadora (AC), assinando solicitações de identidade para as partes confiáveis finais (RPs) que você gerencia.

Processo de integração

Etapa 1: análise de negócios e Termos de Serviço (TOS)

• Análise: o Google vai analisar seus processos de análise e padrões de segurança.
• Assine os TOS:você precisa assinar os Termos de Serviço do registrador de verificador da Carteira do Google.

Etapa 2: estabelecimento de confiança (configuração da AC raiz)

A Carteira do Google usa um modelo de cadeia de confiança.

• Enviar certificado raiz: Forneça seu certificado de AC raiz ao Google.
• O Google vai adicionar seu certificado raiz ao repositório de confiança da Carteira do Google, permitindo que ele verifique todos os certificados emitidos para suas RPs finais.

Etapa 3: integração da RP final

Para cada RP final que você assinar, é necessário:

• Informar o Google:use o formulário de ingestão designado (em breve) para notificar o Google sobre a nova RP e o caso de uso pretendido.
• Configurar metadados:preencha as informações de exibição da RP (nome, logotipo, URL da Política de Privacidade) e defina um nome distinto globalmente exclusivo (assunto) no certificado.

Especificações técnicas

A. Perfil do certificado

As solicitações precisam ser assinadas por certificados X.509 v3 padrão gerados usando P-256 / ECDSA e que contenham uma extensão personalizada do Google:

• OID de extensão personalizada:1.3.6.1.4.1.11129.10.1
• Conteúdo:um hash SHA256 de RelyingPartyMetadataBytes, codificado em uma OCTET STRING ASN.1.

Dica: você pode usar certificados de assinatura intermediários entre os certificados de AC raiz e de folha de RP. Isso permite 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, que são usados para assinar certificados de folha de RP final. Isso facilita a rotação em caso de violação sem afetar a raiz.

B. Esquema de metadados (CBOR)

Os metadados precisam ser codificados no formato CBOR.

; in CDDL for CBOR encoding
; schemaVersion = "v1"

RelyingPartyMetadataBytes = #6.24(bstr .cbor RelyingPartyMetadata)


RelyingPartyMetadata = {
  "schema_version": tstr,
  "display": DisplayInfo,
  "aggregator_info": DisplayInfo  ; Optional: include to show your branding alongside the RP
}

DisplayInfo = {
  "display_name": tstr,
  "logo_uri": tstr,             ; See note below on brand guidelines
  "privacy_policy_uri": tstr
}

O logo_uri precisa seguir as diretrizes de marca da Carteira do Google.

C. Integração do OpenID4VP

Inclua os metadados codificados em base64url no objeto client_metadata:

{
  "client_metadata": {
    "vp_formats_supported": { ... },
    "gw_rp_metadata_bytes": "<base64url encoding of RelyingPartyMetadataBytes>"
  },
  "nonce": "...",
  "response_mode": "dc_api",
  "response_type": "vp_token"
}

Conformidade e revogação

• Monitoramento de abuso:o Google monitora atividades maliciosas de RP e notifica você sobre qualquer abuso detectado.
• Revogação imediata:é necessário revogar imediatamente os certificados de RPs abusivas e publicar uma lista de revogação de certificados (CRL) atualizada.
• Auditoria:o Google mantém registros anônimos para garantir que as solicitações de RP correspondam aos casos de uso registrados.

Próximas etapas

Para começar a integração, entre em contato com seu representante do Google com o certificado de CA raiz proposto e sua lista inicial de RPs finais.