Metadados públicos e discovery
Participantes interoperáveis precisam de forma aprovada para descobrir identificadores, material público de verificação, perfis de credenciais suportados, capacidades de protocolo, schemas e informação de status. Metadados públicos reduzem configuração manual, mas não concedem autorização nem estabelecem confiança sozinhos.
Categorias de metadados
| Categoria | Finalidade pública | Limitação importante |
|---|---|---|
| Identificadores institucionais | Identificar emissor, verificador ou controlador de serviço | Resolução não prova autoridade para todo claim |
| Material de verificação | Publicar chaves ou certificados e relações pretendidas | Material privado e operações internas permanecem protegidos |
| Metadados do emissor | Descrever capacidades e perfis de emissão | Disponibilidade pode variar por produto, tenant e onboarding |
| Metadados de autorização | Descrever serviços compatíveis e recursos de segurança | Discovery não registra cliente nem concede scopes |
| Configurações de credenciais | Identificar tipos, formatos, claims, display e requisitos de prova | Resumos públicos podem omitir schemas e políticas específicas |
| Metadados do verificador | Identificar solicitante e comportamento de apresentação | O titular ainda valida finalidade e contexto |
| Schemas e vocabulários | Definir estrutura e semântica | Validade estrutural não prova verdade do claim |
| Informação de status | Apoiar expiração, suspensão, revogação ou substituição | Status público não deve revelar motivos sensíveis nem histórico |
| Referências de frameworks de confiança | Apontar governança, acreditação ou federação | A confiança é validada contra política local |
| Capacidades do serviço | Descrever padrões e versões suportados | Publicidade não é conformidade universal |
Sequência de discovery
Um participante deve:
- obter a localização dos metadados por bootstrap aprovado;
- recuperá-los por canal autenticado e protegido por integridade;
- validar procedência e controlador esperado;
- confirmar perfil e versão exatos;
- aplicar política local de confiança e algoritmos;
- armazenar em cache apenas na janela aprovada de atualidade;
- detectar mudanças inesperadas;
- falhar com segurança quando metadados obrigatórios não puderem ser resolvidos.
Metadados nunca devem ser aceitos apenas porque foram retornados por redirect não confiável ou incluídos em transação não verificada.
Chaves públicas e material de verificação
O material pode ser exposto por documentos DID, JWKS, certificados ou outro perfil aprovado. Consumidores devem verificar:
- relação entre emissor e controlador;
- identificador da chave e finalidade;
- algoritmo e tipo de chave permitidos;
- estado de ativação, retirada ou revogação;
- caminho de validação de certificado ou DID;
- comportamento de cache e rotação;
- requisitos de verificação histórica.
Uma chave pública nunca deve ser acompanhada de expoente privado, segredo de recuperação, seed ou credencial interna de gerenciamento de chaves.
Metadados de capacidades de credenciais
Podem ajudar Wallet ou parceiro a compreender:
- identificador de configuração;
- formato e perfil;
- nome de exibição e idiomas;
- nomes dos claims e valores esperados;
- requisitos de prova ou holder binding;
- padrões de autorização e entrega;
- modelo de status e validade;
- versão e deprecação.
A representação pública deve ser suficiente para discovery sem expor mappings de clientes, lógica interna de validação ou regras de aprovação em produção.
Schemas e semântica
Um schema deve ser imutável ou claramente versionado após publicação. Mudanças incompatíveis exigem nova versão e plano de migração.
Um registro ou referência deve distinguir:
- restrições estruturais;
- significado semântico;
- autoridade do emissor;
- classificação de divulgação;
- sensibilidade de privacidade;
- ciclo de vida e compatibilidade.
Não se deve presumir que campos com nomes semelhantes possuem o mesmo significado entre tipos de credenciais ou jurisdições.
Metadados de status
Mecanismos de status devem fornecer a informação mínima atual necessária para verificação. Um bom design evita publicar:
- motivos de revogação ligados a uma pessoa;
- inventários completos de credenciais ou titulares;
- identificadores estáveis de correlação;
- dados internos de casos ou incidentes;
- operações administrativas.
O comportamento durante outage deve ser definido por política, e não improvisado em runtime.
Procedência e integridade
Consumidores devem usar controles como:
- validação da origem HTTPS;
- validação DID ou de certificado quando aplicável;
- metadados assinados quando o perfil suporta;
- relações fixadas de emissor ou framework de confiança;
- validação de content type e schema;
- restrições de redirects;
- expiração e refresh do cache;
- monitoramento de mudanças inesperadas de chaves ou capacidades.
Metadados sintaticamente corretos, mas incompatíveis com perfil aprovado, devem ser tratados como evento controlado de compatibilidade.
Versionamento e mudança
Metadados públicos devem identificar versão, estado efetivo e deprecação quando suportados. Parceiros devem receber aviso antecipado de mudanças que afetem:
- identificadores ou schemas de credenciais;
- endpoints ou autorização;
- algoritmos, chaves ou certificados;
- requisitos de prova e holder binding;
- mecanismos de status;
- claims exigidos ou formatos de apresentação;
- semântica de erros;
- expectativas de conformidade.
Rotação pode ser rotineira, mas consumidores ainda precisam de sobreposição, refresh e verificação histórica corretos.
Privacidade e resistência a abuso
Metadados públicos devem publicar capacidades, não segredos operacionais. Devem ser revisados para evitar:
- dados pessoais e vazamento entre tenants;
- hostnames internos ou topologia;
- endpoints administrativos;
- limiares antiabuso;
- relações de clientes não publicadas;
- detalhes operacionais de alto valor para ataques;
- fingerprinting ou enumeração excessiva.
Controle de taxa e monitoramento podem proteger serviços sem impedir interoperabilidade legítima.
Superfícies públicas e de parceiros
A superfície pública pode descrever identificadores estáveis, padrões, capacidades, material público e perfis gerais.
A superfície controlada de parceiros pode incluir metadados do ambiente, schemas exatos, registro de clientes, configurações de teste, participação em frameworks de confiança e notas de compatibilidade.
Limite da documentação pública
Esta página não publica endpoints de produção, identificadores de clientes, redirect locations, inventários de tenants, schemas privados, interfaces administrativas, health interno, capacidades não liberadas ou detalhes de gerenciamento criptográfico.
Consulte Identificadores descentralizados, OpenID para credenciais verificáveis e Onboarding de parceiros.