Construir com a UbID

Construir com a UbID significa integrar um ciclo de confiança, e não apenas chamar um endpoint de identidade. Uma implementação bem-sucedida começa definindo quem está autorizado a emitir evidência, quem a controla, quem a solicita, qual política determina a aceitação e qual evidência deve permanecer disponível após a transação.

A UbID fornece um modelo de integração baseado em funções para emissores, titulares, Wallets, verificadores, partes confiantes, custodiantes e serviços operacionais. Padrões abertos fornecem contratos de intercâmbio; política institucional fornece significado, autoridade e responsabilização.

Comece pela questão de confiança

Antes de selecionar protocolo ou API, a instituição deve declarar a questão que precisa responder. Exemplos:

• Esta pessoa está atualmente vinculada a uma instituição aprovada?
• Este profissional possui qualificação válida para a atividade solicitada?
• Quem apresenta tem direito de usar esta credencial?
• Este claim derivado de documento é apoiado por evidência suficiente?
• Este dispositivo e sessão são adequados para a operação solicitada?

A questão determina claims mínimos, emissores aceitáveis, nível de assurance, contexto de apresentação, requisitos de status, retenção e responsável pela decisão final.

Jornada pública de integração

Uma integração típica progride por estas etapas:

1. Definir funções e finalidade — identificar emissor, titular, Wallet, verificador, parte confiante, controlador, operador e responsáveis operacionais.
2. Projetar o perfil de confiança — definir tipo de credencial, semântica dos claims, emissores aceitos, algoritmos, status, assurance, divulgação e resultados de política.
3. Selecionar o padrão de intercâmbio — escolher contratos aprovados de emissão, apresentação, mensagens, autenticação ou APIs.
4. Descobrir capacidades — resolver identificadores públicos e metadados sem tratar discovery como autorização.
5. Prototipar com dados sintéticos — validar a interação sem usar dados pessoais reais ou credenciais de produção.
6. Concluir onboarding controlado — acordar schemas, ambientes, responsabilidades de segurança, suporte e evidência.
7. Testar casos positivos e negativos — confirmar interoperabilidade, privacidade, resistência a replay, ciclo de vida e decisões fail-closed.
8. Aprovar uso em produção — registrar perfil, versões, responsáveis, controles e readiness operacional exatos.
9. Operar e evoluir — monitorar resultados, rotacionar chaves, administrar status, revisar políticas e coordenar mudanças.

Domínios de integração

Domínio	Objetivo da integração	Principais produtos UbID
Emissão	Converter evidência governada em credencial assinada e entregável	Credential Cloud, Proof, KeyVault, Trust API
Titular e Wallet	Proteger credenciais, obter autorização e produzir apresentações	Wallet, Access, Recover, Connect
Verificação	Validar procedência, integridade, status, contexto e política	Proof, Trust API, Connect
Discovery de confiança	Resolver identificadores, chaves públicas, perfis suportados e status	Connect, Trust API, Credential Cloud
Autenticação e acesso	Estabelecer sessão segura de usuário ou dispositivo	Access, Wallet
Recuperação e continuidade	Restaurar acesso controlado sem criar segredo universal de recuperação	Recover, Wallet, Connect, KeyVault
Operações	Observar postura dos serviços e manter evidência explicável	Pulse, Sentinel AI

Contratos estáveis, componentes internos substituíveis

Integrações externas devem depender de contratos versionados, e não de bancos de dados internos, nomes de contêineres, bibliotecas de implementação ou topologia de serviços. UbID Trust Gateway e APIs de produtos fornecem uma fronteira controlada entre protocolos externos e domínios internos de confiança.

Essa separação permite:

• evolução independente de componentes internos;
• validação explícita nos limites de confiança;
• autorização e evidência consistentes;
• adaptação de protocolos sem expor estado interno;
• responsabilidades mais claras de incidentes e suporte;
• menor acoplamento entre parceiros e operações da plataforma.

Documentação pública e documentação de parceiros

Este portal descreve arquitetura pública, responsabilidades, padrões de ciclo de vida, posicionamento de padrões, conceitos de metadados, etapas de onboarding e limites de publicação.

A documentação controlada de parceiros pode acrescentar:

• perfis exatos de APIs e protocolos;
• metadados específicos do ambiente;
• definições e schemas aprovados de credenciais;
• requisitos de registro e autorização de clientes;
• vetores de teste e casos de conformidade;
• canais de suporte e níveis de serviço;
• procedimentos de mudança, deprecação e aprovação de produção.

Credenciais de produção, trust lists privadas, configuração de clientes, material criptográfico, topologia interna e operações administrativas nunca são distribuídos pelo portal público.

Princípios de integração

Toda integração deve preservar estas regras:

• Finalidade antes dos dados — solicitar apenas a evidência exigida para transação declarada.
• Funções antes de endpoints — atribuir autoridade e responsabilidade antes de selecionar interfaces.
• Política antes da automação — definir o que é aceitável antes de automatizar uma decisão.
• Verificação antes da aceitação — validade criptográfica é apenas uma entrada da política institucional.
• Autorização antes da apresentação — o titular deve entender o que foi solicitado e para quê.
• Ciclo de vida antes do lançamento — definir expiração, status, renovação, substituição, revogação e recuperação.
• Evidência sem segredos — manter decisões explicáveis sem registrar chaves privadas, conteúdo completo de Wallet ou dados pessoais desnecessários.
• Mudança versionada — fixar perfis e tratar mudanças inesperadas de metadados ou comportamento como eventos controlados de compatibilidade.

Questões de readiness

Antes de solicitar acesso de parceiro, a equipe de integração deve conseguir responder:

• Qual organização é autoritativa para cada claim?
• Quais credenciais e claims são realmente necessários?
• Qual assurance é exigido e como será evidenciado?
• Quem responde pela decisão final de negócio ou jurídica?
• Quais identificadores e metadados precisam ser resolvíveis publicamente?
• Como status, expiração, substituição e revogação serão tratados?
• O que acontece quando uma dependência está indisponível ou o resultado é indeterminado?
• Quais dados serão retidos, por quanto tempo e sob qual função?
• Quais testes negativos devem passar antes da aprovação de produção?
• Quem responde por rotação de chaves, incidentes, suporte e notificação de mudanças?

Continue com Modelo de integração, Integração do emissor, Integração do verificador ou Onboarding de parceiros.