Pular para o conteúdo principal

OpenID para credenciais verificáveis

OpenID for Verifiable Credentials define contratos de protocolo para duas interações diferentes:

  • OpenID4VCI coordena a emissão de credenciais entre uma Wallet e um emissor de credenciais.
  • OpenID4VP coordena solicitações e apresentações de credenciais entre um verificador e uma Wallet.

Os protocolos são construídos sobre mecanismos estabelecidos de OAuth e OpenID, mantendo a capacidade de transportar diferentes formatos de credenciais.

Emissão com OpenID4VCI​

Um fluxo de emissão pode incluir:

  1. discovery de metadados do emissor e configurações de credenciais suportadas;
  2. uma oferta de credencial ou outro mecanismo de iniciação;
  3. autorização da Wallet ou do usuário final;
  4. prova de que a Wallet controla o material de chaves exigido;
  5. emissão de uma ou mais credenciais;
  6. entrega diferida ou notificação quando houver suporte;
  7. informações de ciclo de vida necessárias para uso posterior.

O protocolo define como a interação é coordenada. Ele não decide se a pessoa solicitante passou por proofing suficiente nem se o emissor está legalmente autorizado a emitir a credencial.

Apresentação com OpenID4VP​

Um fluxo de apresentação pode incluir:

  1. solicitação do verificador descrevendo a evidência necessária;
  2. identidade do verificador e informação de finalidade;
  3. avaliação pela Wallet de credenciais compatíveis;
  4. revisão e autorização do titular;
  5. criação de resposta recente e vinculada à audiência;
  6. validação e avaliação de política pelo verificador;
  7. decisão institucional fora do protocolo.

Uma resposta de apresentação é evidência para uma decisão, e não a decisão em si.

Digital Credentials Query Language​

OpenID4VP define DCQL, linguagem de consulta codificada em JSON pela qual um verificador pode descrever credenciais aceitáveis, claims, alternativas e combinações.

DCQL pode melhorar a interoperabilidade tornando as solicitações mais explícitas, mas uma consulta tecnicamente válida ainda pode ser desproporcional. A UbID exige que o design da solicitação respeite limitação de finalidade e minimização.

Interações no mesmo dispositivo e entre dispositivos​

Interações entre Wallet e verificador podem ocorrer no mesmo dispositivo ou entre dispositivos. Códigos QR, deep links, redirects, APIs mediadas pelo navegador ou outros mecanismos aprovados de iniciação podem ser usados conforme o perfil.

Cada perfil deve definir proteções para:

  • autenticidade da solicitação;
  • validação de redirect e origem;
  • tratamento de nonce e state;
  • resistência a replay;
  • vínculo de audiência;
  • criptografia da resposta quando exigida;
  • consentimento do usuário e contexto da transação;
  • timeout e comportamento de abandono.

Independência de formato da credencial​

OpenID4VCI e OpenID4VP são protocolos de transporte e coordenação. Eles podem suportar formatos como credenciais baseadas em SD-JWT, W3C Verifiable Credentials ou documentos móveis ISO quando definidos pelo perfil do ecossistema.

Compatibilidade de protocolo não significa compatibilidade de formato. Wallets, emissores e verificadores devem concordar sobre formato exato, perfil, algoritmos, mecanismo de status e semântica dos claims.

Metadados e discovery​

Metadados públicos podem descrever emissores, authorization servers, configurações de credenciais, formatos, algoritmos, endpoints e capacidades de apresentação suportados. Metadados permitem automação, mas não substituem governança de confiança.

Um parceiro deve validar a procedência dos metadados, fixar perfis aprovados, rejeitar combinações não suportadas e tratar mudanças inesperadas como eventos controlados de compatibilidade.

Posição da UbID​

A arquitetura de referência da UbID identifica emissão alinhada a OpenID4VCI e apresentação alinhada a OpenID4VP como contratos preferenciais de interoperabilidade. As especificações externas são especificações finais da OpenID, mas o status da capacidade UbID e os subconjuntos suportados permanecem específicos de produto e deployment.

A documentação e os perfis de parceiros devem distinguir:

  • arquitetura alinhada;
  • fluxo implementado;
  • perfil de interoperabilidade testado;
  • disponibilidade em produção;
  • conformidade certificada ou avaliada de forma independente.

Esses termos não são intercambiáveis.

Limite da documentação pública​

Esta página não publica metadados de produção, identificadores de clientes, redirect URIs, transaction codes, ofertas de credenciais, valores de sessão, DCQL de clientes, schemas privados nem contratos de endpoints específicos de ambiente.

Padrões-fonte​

Consulte Integração do emissor, Integração do verificador e Integração de Wallet e titular.