Integração do verificador
Uma integração de verificador formula uma questão de confiança, solicita evidência proporcional, valida a resposta e retorna um resultado explicável de política à instituição confiante. Não deve coletar perfil completo apenas porque há mais dados tecnicamente disponíveis.
Definir a finalidade
O verificador deve documentar:
- transação e parte confiante;
- decisão que exige evidência;
- tipos de credenciais e emissores aceitáveis;
- claims mínimos ou declarações derivadas;
- requisitos de assurance, atualidade e holder binding;
- comportamento de status e dependências;
- requisitos de retenção e comprovantes;
- caminhos de revisão humana ou recurso;
- responsável pela decisão institucional final.
A solicitação deve ser explicável ao titular e proporcional à finalidade.
Projetar a solicitação
Uma solicitação pode definir:
- formatos e perfis aceitáveis;
- emissores ou marcos de confiança;
- claims obrigatórios e opcionais;
- credenciais alternativas ou combinações de evidência;
- atualidade, audiência e vínculo transacional;
- relação com titular ou key binding;
- finalidade e informação da parte confiante;
- proteção e expiração da resposta;
- expectativas de autorização e experiência do usuário.
Uma consulta conforme aos padrões ainda pode ser excessiva. Revisão de política e privacidade continua necessária.
Pipeline de verificação
Um verificador representativo executa:
- Integridade da solicitação — confirma atualidade, autenticidade e associação com a parte correta.
- Parsing da resposta — rejeita estruturas malformadas, ambíguas ou não suportadas.
- Validação de formato — aplica o perfil exato aprovado.
- Resolução do emissor — resolve emissor e material de verificação por caminhos aprovados.
- Validação de assinatura ou prova — verifica integridade com algoritmos e relações de chave permitidos.
- Ciclo de vida — verifica validade, status, substituição e condições atuais.
- Contexto da apresentação — valida nonce, audiência, state, tempo e replay.
- Relação com o titular — verifica o vínculo exigido pelo perfil.
- Conformidade da divulgação — confirma claims obrigatórios e evita tratar dados não relacionados como necessários.
- Política de confiança e assurance — avalia escopo do emissor, tipo, assurance, jurisdição e regras da transação.
- Geração do resultado — produz resultado explicável e referência de evidência.
- Decisão da parte confiante — permite aplicar regras de negócio, legais, de segurança ou acesso fora do protocolo.
Verificação não é um único booleano
| Resultado | Significado |
|---|---|
| Verificada e conforme | Condições técnicas e de confiança exigidas foram aprovadas |
| Válida, mas insuficiente | O artefato é autêntico, mas não atende à política |
| Falha de ciclo de vida | Expirada, suspensa, revogada ou substituída |
| Fonte não confiável | Emissor ou tipo fora do escopo aprovado |
| Falha de contexto | Antiga, reproduzida, endereçada incorretamente ou sem vínculo transacional |
| Falha de relação com titular | O vínculo exigido não foi comprovado |
| Não suportada | Formato, algoritmo, schema ou perfil não aceito |
| Indeterminada | Dependência autoritativa indisponível ou inconclusiva |
| Revisão necessária | A política encaminha o resultado a processo humano autorizado |
A parte confiante não deve reinterpretar resultado indeterminado ou não suportado como verificação bem-sucedida.
Política de confiança
O verificador deve saber não só quem emitiu a credencial, mas se o emissor é confiável para o tipo e a finalidade. A confiança pode ser delimitada por:
- jurisdição e setor;
- definição de credencial;
- nível de assurance;
- algoritmo e tipo de chave;
- mecanismo de status;
- modelo de holder binding;
- risco da transação;
- validade e atualidade;
- certificação ou participação em framework quando houver evidência independente.
Registros de confiança e versões de política são ativos controlados. Sua representação pública não deve revelar lógica de aceitação de clientes nem relações privadas.
Verificação com privacidade
O verificador deve minimizar:
- claims solicitados;
- frequência de apresentação e identificadores de correlação;
- material de credenciais retido;
- documentos de origem e evidência de proofing;
- logs com dados pessoais;
- distribuição de comprovantes.
Quando possível, a aplicação confiante deve receber somente claims e resultado de política necessários, e não o artefato completo de apresentação.
Comprovantes e evidência
Um comprovante pode identificar:
- solicitação e transação;
- verificador e parte confiante;
- finalidade declarada;
- tipo de credencial e referência do emissor;
- verificações realizadas e versão de política;
- nomes dos claims divulgados ou resultado minimizado;
- status e resultados de dependências;
- categoria final e timestamp.
Ele não deve tornar-se um dossiê reutilizável. Retenção e acesso devem estar vinculados à finalidade.
Dependências e falhas
O perfil deve definir se falha fechado, repete ou encaminha para revisão quando:
- metadados do emissor não são resolvidos;
- uma chave está ausente, retirada ou não aprovada;
- status não pode ser verificado;
- apresentação está incompleta ou antiga;
- relógios, caches ou versões divergem;
- registro externo de confiança está indisponível;
- formato é sintaticamente válido, mas fora do perfil fixado.
Downgrade silencioso de controle obrigatório para verificação mais fraca não é aceitável.
Expectativas de testes
Os testes devem incluir:
- assinaturas válidas e inválidas;
- emissor ou tipo incorreto;
- credenciais expiradas, revogadas, suspensas e substituídas;
- algoritmos não suportados e disclosures malformadas;
- audiência, nonce, state ou transação incorretos;
- respostas reproduzidas e duplicadas;
- holder binding ausente;
- claims excessivos ou inesperados;
- rotação de metadados e refresh de cache;
- indisponibilidade de dependência e resultados indeterminados;
- migração de versão de política.
Checklist de readiness do verificador
Antes da produção, confirmar que:
- questão de confiança e responsável pela decisão são explícitos;
- solicitações coletam somente evidência necessária;
- escopos de confiança são governados;
- algoritmos, formatos, status e holder binding estão fixados;
- resultados são explicáveis além de válido/inválido;
- fail-closed e revisão estão definidos;
- comprovantes são minimizados e retidos adequadamente;
- passam testes negativos e de replay;
- mudanças de política e metadados são monitoradas;
- responsáveis por suporte, incidentes e recurso estão atribuídos.
Limite da documentação pública
Esta página não expõe metadados de produção, definições de solicitações de clientes, trust lists privadas, limiares de aceitação, regras de fraude, código de política, registros de clientes, schemas de comprovantes nem procedimentos de exceção.
Consulte Verificação e política, Confiança e política e OpenID para credenciais verificáveis.