Confiança e política
Política de confiança converte evidência criptográfica em decisão contextual. Uma assinatura válida confirma integridade sob uma chave; a política determina se emissor, chave, credencial, disclosure, relação com titular e transação são aceitáveis para a finalidade declarada.
Camadas de política
| Camada | Responsabilidade de exemplo |
|---|---|
| Política de participantes | Quais emissores, Wallets, verificadores ou partes confiantes são reconhecidos |
| Política de credenciais | Quais tipos, schemas, perfis e significados de claims são aceitos |
| Política criptográfica | Formatos, algoritmos, tipos de chave, relações e deprecações permitidos |
| Política de ciclo de vida | Validade, status, suspensão, revogação, substituição e dependências |
| Política de apresentação | Claims exigidos, alternativas, minimização, audiência, nonce e holder binding |
| Política de assurance | Proofing, fontes de evidência, nível de revisão e risco exigidos |
| Política jurisdicional | Finalidade, base legal, biometria, retenção, transferências e direitos |
| Política de negócio | Elegibilidade, acesso, segurança, fraude, sanções, clínica ou setor |
| Política operacional | Timeout, repetição, revisão, outages, monitoramento, evidência e incidentes |
Essas camadas devem ser versionadas independentemente quando possuem responsáveis e ciclos de mudança diferentes.
A confiança tem escopo
Um emissor deve ser confiável apenas para claims e contextos que está autorizado a apoiar. A confiança pode ser limitada por:
- tipo de credencial;
- população de sujeitos;
- jurisdição;
- setor ou domínio profissional;
- nível de assurance;
- período de validade;
- perfil de algoritmo e chave;
- finalidade do verificador ou parte confiante;
- participação em framework governado de forma independente.
Emissor confiável de vínculo empregatício não é automaticamente confiável para identidade civil, diplomas acadêmicos, licenças médicas ou elegibilidade financeira.
Fontes de confiança
A política pode usar fontes governadas como:
- allow-lists institucionais explícitas;
- registros de confiança ou metadados de federação;
- relações contratuais de parceiros;
- evidência de certificação ou acreditação;
- governança de domínio e DID;
- infraestrutura de chave pública aprovada;
- registros setoriais ou governamentais;
- registros de exceções aprovados manualmente.
A existência de identificador ou chave pública não basta. Procedência e autorização devem ser estabelecidas.
Política de credenciais e schemas
A política deve fixar a definição aceita e a semântica dos claims. Deve rejeitar schemas ambíguos ou alterados silenciosamente mesmo quando continuam tecnicamente parseáveis.
Um perfil deve definir:
- modelos de emissor e sujeito;
- claims obrigatórios e opcionais;
- formatos de valores e vocabulários;
- regras de disclosure;
- modelo de holder binding;
- mecanismo de status;
- validade e renovação;
- categoria de evidência e assurance;
- compatibilidade de versões.
Validação de schema confirma estrutura, não verdade nem autorização.
Política de algoritmos e chaves
A política criptográfica deve permitir somente combinações revisadas de:
- formato da credencial;
- algoritmo de assinatura ou prova;
- tipo e tamanho da chave;
- relação de verificação;
- status e ciclo de vida da chave;
- caminho de validação de certificado, DID ou registro;
- prova do titular e key binding;
- criptografia da resposta quando exigida.
Combinações inesperadas, deprecadas, fracas ou não suportadas devem falhar com segurança. Agilidade não significa aceitar toda opção anunciada.
Política de status e atualidade
Uma credencial pode ser autêntica e inaceitável por estar expirada, suspensa, revogada, substituída ou fora de contexto.
A política deve definir:
- se verificação de status é obrigatória;
- idade aceitável do cache e comportamento de dependências;
- tratamento de expiração e tolerância de relógio;
- uso histórico de credenciais superadas;
- quais resultados vão para revisão;
- efeito de indisponibilidade de status conforme o risco.
Um verificador nunca deve ignorar silenciosamente uma verificação obrigatória e ainda alegar verificação completa.
Assurance e risco
A mesma credencial pode ser suficiente para uma transação e insuficiente para outra. A política pode combinar:
- autoridade do emissor;
- assurance de proofing ou evidência;
- holder binding;
- assurance de dispositivo e sessão;
- idade da credencial;
- valor ou impacto da transação;
- indicadores contextuais de risco;
- revisão humana obrigatória.
Rótulos de assurance devem ser apoiados por controles e evidência explícitos, e não apenas linguagem de marketing.
Resultados de política
Um motor de políticas deve retornar categoria explicável, e não apenas booleano. Pode incluir:
- satisfeita;
- evidência insuficiente;
- emissor ou perfil não confiável;
- falha de ciclo de vida;
- falha de contexto ou holder binding;
- algoritmo ou formato não suportado;
- dependência indisponível;
- revisão necessária;
- erro de configuração de política.
O resultado deve identificar versão e categoria do motivo sem expor lógica sensível de fraude nem detalhes internos.
Ciclo de governança da política
A política deve passar por:
- proposta e atribuição de responsável;
- revisão de arquitetura, segurança, privacidade, jurídico ou negócio;
- definição de vetores de teste e casos negativos;
- aprovação controlada;
- ativação gradual;
- observação em produção;
- revisão periódica;
- migração ou retirada.
Toda mudança material deve identificar credenciais, parceiros, titulares, decisões históricas, metadados, testes e condições de rollback afetados.
Testes de política
Os testes devem incluir:
- emissores aprovados e não aprovados;
- datas-limite e mudanças de status;
- chaves rotacionadas e retiradas;
- disclosures malformadas ou excessivas;
- prova do titular ausente;
- apresentações reproduzidas ou com audiência incorreta;
- algoritmos e versões não suportados;
- outage do registro de confiança;
- caminhos de revisão e exceção;
- migração da versão anterior.
Limite da documentação pública
Esta página descreve arquitetura de políticas. Registros de produção de confiança, regras de aceitação de clientes, indicadores de fraude, allow-lists de algoritmos, código-fonte de políticas, limiares, registros de exceções e overrides de emergência permanecem controlados.
Consulte Verificação e política, Metadados públicos e discovery e Status de conteúdo e capacidades.