Integração do emissor
Uma integração de emissor converte evidência institucional autoritativa em credencial que pode ser mantida, apresentada e verificada de forma independente. O emissor continua responsável pela verdade, escopo, governança e ciclo de vida dos claims que assina.
A UbID coordena proofing, política, definição de credencial, assinatura, entrega, status e evidência, mantendo essas responsabilidades governáveis de forma independente.
Estabelecer autoridade emissora
Antes de implementar um fluxo, a organização deve documentar:
- base legal ou institucional para emitir o claim;
- população e jurisdição abrangidas;
- sistemas-fonte ou evidências considerados autoritativos;
- assurance exigido antes da emissão;
- quem pode aprovar, suspender, revogar, substituir ou renovar credencial;
- procedimentos de retenção e direitos associados;
- contextos de uso pretendidos.
Uma organização tecnicamente capaz não está automaticamente autorizada a emitir todo tipo de claim.
Definir a credencial
| Área | Questões a resolver |
|---|---|
| Identidade | Quem são emissor, sujeito e titular pretendido? |
| Semântica | O que cada claim significa e qual fonte o estabelece? |
| Minimização | Quais claims são necessários, opcionais ou proibidos? |
| Schema | Como campos, formatos e versões são validados? |
| Assurance | Qual evidência e nível de revisão apoiam a emissão? |
| Vínculo | Como a credencial se associa ao titular ou Wallet pretendidos? |
| Ciclo de vida | Quando expira, renova, suspende, revoga ou é superada? |
| Status | Como o verificador determina a aceitabilidade atual? |
| Privacidade | Quais disclosures são esperadas e quais correlações devem ser limitadas? |
| Governança | Quem responde por mudanças, incidentes, suporte e comunicação? |
Schemas fornecem consistência, mas não provam que o claim de origem é verdadeiro. Evidência, autoridade e política permanecem essenciais.
Fluxo de emissão
Um fluxo representativo contém:
- Iniciação — processo autorizado inicia transação para credencial definida.
- Coleta de evidência — evidência mínima é obtida de fontes aprovadas.
- Proofing e validação — evidência de identidade, documento, instituição ou outra é avaliada.
- Avaliação de política — autoridade, elegibilidade, assurance, schema, duplicados e ciclo de vida são verificados.
- Vínculo com titular ou Wallet — o destinatário prova a relação exigida pelo perfil.
- Aprovação — pessoa ou política autorizada concede a emissão.
- Assinatura — serviço criptográfico controlado assina os claims aprovados com versão identificável da chave.
- Entrega — credencial é entregue por interação aprovada com o titular.
- Registro e status — referências coerentes de ciclo de vida e status são criadas.
- Evidência — emissor mantém registro auditável sem material secreto desnecessário.
As etapas podem ocorrer de modo síncrono ou assíncrono. Resultado bem-sucedido de proofing não deve tornar-se assinatura automática sem transição explícita de política.
Preparar, validar, aprovar e executar
APIs do emissor devem separar intenção e mudança autoritativa de estado:
- Prepare monta solicitação e referências de apoio.
- Validate verifica sintaxe, schema, evidência, identidade, duplicados e política.
- Approve registra a autorização exigida.
- Execute cria e assina a credencial.
A estrutura favorece segregação de funções, revisão humana, idempotência e falhas explicáveis.
Responsabilidade de chaves e assinatura
O emissor responde pelo significado da assinatura e governança de sua identidade de assinatura. Aplicações devem solicitar operação limitada a serviço aprovado de chaves, sem receber material institucional privado.
O perfil de parceiro deve definir:
- identificador do emissor e relação de verificação;
- formato e algoritmos aprovados;
- ativação, rotação, retirada e resposta a comprometimento de chaves;
- como verificadores resolvem material público;
- como credenciais históricas permanecem revisáveis;
- qual evidência vincula credencial e versão da chave.
Identificadores de chaves de produção, configuração interna de KMS e procedimentos operacionais de recuperação não são documentação pública.
Entrega ao titular
A entrega deve confirmar:
- interação pretendida de Wallet ou titular;
- autorização e atualidade da transação;
- prova de controle de chave exigido;
- estado one-time ou resistente a replay;
- informação clara sobre emissor e credencial;
- comportamento de timeout, abandono e repetição;
- resultado final visível ao emissor sem expor conteúdo da Wallet.
Entrega bem-sucedida não autoriza o emissor a monitorar todos os usos posteriores.
Status, renovação e substituição
O emissor deve manter ciclo coerente:
- ativa — utilizável atualmente segundo política;
- expirada — fora do período de validade;
- suspensa — temporariamente inaceitável;
- revogada — não mais aceitável;
- superada — substituída por credencial nova;
- renovada — reemitida conforme política.
Os estados exatos dependem do perfil. Status público deve revelar apenas o necessário e evitar motivos sensíveis ou histórico do titular.
Claim ou perfil alterado normalmente deve produzir novo artefato assinado e transição coerente, e não mutação de credencial existente.
Resultados de erro e revisão
A integração deve distinguir:
- input incompleto ou inválido;
- configuração não suportada;
- evidência insuficiente ou indeterminada;
- falha de elegibilidade ou política;
- falha de holder binding;
- status duplicado ou conflitante;
- transação antiga, reutilizada ou consumida;
- operação aguardando revisão;
- dependência de assinatura ou entrega indisponível;
- credencial criada com resultado de entrega não resolvido.
Erros devem permitir recuperação segura sem revelar regras antiabuso, dados de outras pessoas ou topologia interna.
Evidência do emissor
O emissor pode manter referências a:
- definição da credencial e versão de schema;
- fonte e categoria de assurance;
- decisão de política e aprovador;
- resultado de holder binding;
- referência da versão da chave de assinatura;
- resultado de emissão e entrega;
- eventos de status e ciclo de vida;
- categoria de motivo para correção, renovação, suspensão ou revogação.
A retenção deve estar vinculada à finalidade e considerar a jurisdição. Evidência bruta não deve ser duplicada apenas porque uma credencial foi emitida.
Checklist de readiness do emissor
Antes da produção, confirmar que:
- autoridade emissora e propriedade dos claims estão documentadas;
- schema e semântica estão aprovados;
- dados mínimos e divulgação estão definidos;
- proofing e assurance são testáveis;
- ciclo de chaves e discovery para verificadores são governados;
- holder binding e entrega resistem a replay;
- status, renovação, substituição e revogação são operacionais;
- passam testes positivos, negativos, duplicados, expiração e dependências;
- responsáveis por suporte e incidentes estão atribuídos;
- declarações públicas descrevem o escopo implementado.
Limite da documentação pública
Esta página não publica schemas de clientes, mappings de sistemas-fonte, metadados de produção, contratos de endpoints, registros de clientes, configuração de assinatura, regras de aprovação, limiares antifraude nem credenciais operacionais. Esses detalhes são fornecidos em onboarding controlado.
Consulte UbID Credential Cloud, OpenID para credenciais verificáveis e Metadados públicos e discovery.