Modelo de integração

Uma integração UbID é uma relação governada entre participantes que trocam evidência verificável. O fluxo técnico é apenas parte do modelo. Autoridade, finalidade, responsabilidade de dados, política de confiança, ciclo de vida e evidência operacional devem ser definidos em conjunto.

Participantes e responsabilidades

Participante	Responsabilidade principal	Não se deve presumir que
Emissor	Valida a base dos claims e emite credenciais governadas	Toma a decisão final da parte confiante
Sujeito	Pessoa ou entidade descrita pelos claims	Sempre é a mesma parte que o titular
Titular	Controla o recebimento e a apresentação de credenciais	Determina se um emissor é confiável para todos os verificadores
Wallet ou serviço do titular	Protege credenciais, chaves, autorização e contexto de apresentação	Divulga silenciosamente credenciais ou claims não relacionados
Verificador	Valida evidência apresentada e avalia política	Trata assinatura válida como direito automático
Parte confiante	Toma a decisão institucional ou de negócio final	Delega toda responsabilidade à tecnologia de credenciais
Provedor de proofing	Produz evidência ou assurance usado por emissor ou política	Torna-se emissor apenas por fornecer evidência
Custodiante ou participante de recuperação	Protege responsabilidade limitada de recuperação	Reconstrói ou controla sozinho a identidade completa
Provedor de infraestrutura	Opera serviços aprovados da plataforma	Usa acesso operacional como autoridade sobre a verdade dos claims

Uma organização pode exercer mais de uma função, mas cada função deve permanecer explícita em políticas, contratos, controle de acesso, evidência de auditoria e procedimentos de incidentes.

O contrato de confiança

O perfil de integração deve registrar pelo menos:

1. Finalidade — transação ou serviço para o qual a evidência é solicitada.
2. Definição da credencial — emissor, tipo, sujeito, semântica dos claims, schema e ciclo de vida.
3. Assurance — evidência e processo exigidos antes da emissão ou aceitação dos claims.
4. Divulgação — claims mínimos e condições de apresentação permitidas.
5. Política criptográfica — formatos, algoritmos, relações de chaves, holder binding e atualidade.
6. Política de status — expiração, suspensão, revogação, substituição e comportamento de dependências.
7. Responsável pela decisão — ator que responde pelo resultado final e caminho de revisão.
8. Governança de dados — finalidade legal, retenção, exclusão, direitos, transferências e condições biométricas.
9. Evidência operacional — identificadores, versão da política, timestamps, resultados e referências mantidos sem segredos.
10. Governança de mudanças — compatibilidade, migração, deprecação e notificação de incidentes.

Sequência de integração ponta a ponta

Uma interação representativa segue este padrão:

1. O emissor define uma credencial aprovada e a evidência necessária para emiti-la.
2. O sujeito ou titular conclui o proofing e o fluxo de autorização aprovados.
3. O emissor valida evidência e política e autoriza a criação.
4. Um serviço controlado de assinatura produz a credencial com chave e algoritmo aprovados.
5. A credencial é entregue ao titular por uma interação aprovada de Wallet.
6. Um verificador solicita a evidência mínima para uma finalidade declarada.
7. O titular revisa a solicitação e autoriza uma apresentação adequada.
8. O verificador valida procedência, integridade, status, contexto, relação com o titular e política.
9. A parte confiante toma a decisão final.
10. Cada participante mantém a evidência necessária para sua própria responsabilização sem coletar todo o ciclo de vida do titular.

A sequência pode ser implementada com fluxos baseados em padrões ou APIs governadas, mas as responsabilidades de confiança permanecem iguais.

Limites da integração

A UbID separa quatro responsabilidades arquitetônicas:

Canais de experiência

Portais, Wallets, aplicações móveis e interfaces de parceiros coletam a intenção do usuário e exibem resultados. Não decidem independentemente confiança de credenciais nem executam operações criptográficas irrestritas.

Serviços de confiança

Serviços de proofing, emissão, verificação, acesso e recuperação avaliam política autoritativa e gerenciam estado de domínio.

Serviços de controle da plataforma

Gerenciamento de chaves, mensagens, resolução de identificadores, status, evidência e componentes compartilhados fornecem controles reutilizáveis por contratos limitados.

Serviços operacionais

Monitoramento, alertas, auditoria e interpretação assistida por IA observam e explicam. Não alteram silenciosamente estado de identidade ou credenciais.

Padrões de interação

Intercâmbio baseado em padrões

Interações entre Wallet, emissor e verificador devem usar perfis reconhecidos quando fornecerem interoperabilidade adequada. O subconjunto exato suportado deve ser fixado e testado.

Coordenação por APIs governadas

Sistemas institucionais podem usar contratos da UbID Trust API para preparar, validar, aprovar, executar e recuperar resultados. Autorização para descobrir capacidade é diferente de autorização para executá-la.

Mensagens seguras entre agentes

DIDComm pode transportar mensagens protegidas vinculadas à identidade quando coordenação assíncrona ou agent-to-agent é necessária. Mensagens não substituem política de emissão ou verificação.

Integração de eventos e evidência

Sistemas autorizados podem receber notificações de ciclo de vida ou referências de evidência. Eventos devem ter escopo, autenticação, resistência a replay e design que evite replicação desnecessária de dados pessoais.

Minimização de dados no design

Arquitetos devem distinguir:

• evidência de origem usada para proofing;
• claims colocados na credencial;
• disclosures selecionadas para uma apresentação;
• resultados de verificação enviados à parte confiante;
• registros operacionais mantidos para responsabilização.

São conjuntos de dados diferentes e não devem ser copiados juntos por padrão. Um verificador geralmente precisa de resultado de política e poucos claims, e não do documento de origem, credencial completa, inventário de Wallet ou registro de proofing.

Modelo de falhas e dependências

A integração deve definir comportamento para:

• metadados do emissor ou chave não resolvidos;
• serviço de status indisponível;
• credencial expirada ou substituída;
• apresentação antiga ou reproduzida;
• formato ou algoritmo não suportado;
• divulgação incompleta;
• resultado indeterminado de proofing;
• incompatibilidade de versão de política;
• timeout do parceiro ou solicitação duplicada;
• degradação operacional.

Fluxos de alto assurance devem falhar de forma fechada ou ir para revisão explícita, em vez de enfraquecer silenciosamente a política.

Evidência de integração

Um registro útil pode identificar:

• participantes e transação;
• finalidade declarada e tipo de credencial solicitado;
• versões de política e schema;
• verificações executadas;
• resultado e categoria do motivo;
• referência de autorização ou consentimento;
• timestamps e resultados de dependências;
• ação de ciclo de vida ou referência da decisão final.

Ele não deve conter chaves privadas, recovery shares, conteúdo completo de Wallet, templates biométricos ou documentos de origem desnecessários.

Limite da documentação pública

Este modelo define a arquitetura pública de confiança. Identificadores de tenants, endpoints de produção, schemas exatos de mensagens, credenciais, registros de confiança, código de política, mapas de infraestrutura, limiares operacionais e procedimentos de exceção permanecem em documentação controlada de parceiros ou interna.

Consulte Confiança e política, Metadados públicos e discovery e Funções e responsabilidades.