Padrões e interoperabilidade
A UbID foi projetada como um tecido de confiança interoperável, e não como um silo fechado de identidade. Padrões abertos definem como identificadores são resolvidos, credenciais são representadas, Wallets interagem com emissores e verificadores, usuários se autenticam, serviços recebem autorização, agentes trocam mensagens protegidas e assistentes de software descobrem capacidades governadas.
Os padrões estabelecem contratos comuns entre participantes que podem usar produtos e stacks tecnológicos internos diferentes. Eles não eliminam a necessidade de governança, política, engenharia de segurança, controles de privacidade, testes ou responsabilização institucional.
Camadas de interoperabilidade
| Camada | Principais padrões ou perfis | Finalidade no modelo UbID |
|---|---|---|
| Identificação e resolução | DID Core e did:web | Publicar identificadores resolvíveis, métodos de verificação e referências de serviço. |
| Semântica de credenciais | W3C Verifiable Credentials Data Model | Expressar de forma consistente emissor, titular, sujeito, claims, schema, status e evidência. |
| Divulgação seletiva | SD-JWT e perfis de credenciais baseados em SD-JWT | Permitir que o titular divulgue claims selecionados em vez do payload completo. |
| Emissão de credenciais | OpenID4VCI | Coordenar ofertas, autorização, prova e entrega entre Wallet e emissor. |
| Apresentação de credenciais | OpenID4VP e DCQL | Solicitar e retornar credenciais ou apresentações adequadas para uma finalidade definida. |
| Autenticação web | WebAuthn e FIDO2 | Fornecer autenticação de chave pública resistente a phishing e passkeys. |
| Federação e sessões | OpenID Connect | Estabelecer sessões web autenticadas e assertions interoperáveis de identidade. |
| Autorização de APIs | OAuth 2.0, PKCE e boas práticas atuais de segurança | Delegar acesso limitado a APIs protegidas. |
| Mensagens de agentes | DIDComm Messaging | Trocar mensagens criptografadas vinculadas à identidade, independentemente de transporte específico. |
| IA e ferramentas | Model Context Protocol | Expor resources e tools a assistentes autorizados por contrato de integração governado. |
Outros padrões podem contribuir para controles especializados, incluindo JSON Schema para validação, JOSE e COSE para envelopes criptográficos, formatos de listas de status, OHTTP e HPKE para privacidade de transporte e padrões pós-quânticos para criptoagilidade de longo prazo. Seu uso deve ser declarado pelo produto ou perfil de parceiro relevante, e não inferido do nome da plataforma.
Quatro dimensões da interoperabilidade
Sintaxe
Os participantes devem concordar sobre como a informação é codificada e transportada. Exemplos incluem JSON, JWT, JWS, JWK, HTTP e envelopes de mensagens DIDComm.
Semântica
Um objeto JSON tecnicamente válido não é interoperável se os participantes atribuírem significados diferentes aos seus campos. Tipos de credenciais, definições de claims, versões de schemas, significados de status, níveis de assurance e definições de finalidade precisam ser governados.
Confiança
Interoperabilidade não significa aceitar todos os emissores, chaves, algoritmos, Wallets ou verificadores. Cada instituição ainda aplica registros de confiança, política de emissores, política de algoritmos, verificações de status, requisitos de assurance e controles de risco.
Operações
A interoperabilidade em produção também exige negociação de versões, discovery de metadados, tratamento de erros, proteção contra replay, gerenciamento do ciclo de vida, testes de conformidade, monitoramento e governança de mudanças.
Maturidade do padrão e maturidade da UbID são diferentes
Uma especificação pode ser final enquanto uma capacidade específica da UbID permanece planejada, limitada ou disponível apenas para parceiros. Inversamente, a UbID pode implementar um perfil controlado baseado em um draft, identificando claramente a versão fixada e as obrigações de migração.
O portal público, portanto, separa:
- maturidade externa da especificação;
- função arquitetônica atribuída;
- status atual da capacidade UbID;
- subconjunto habilitado em deployment específico;
- evidência de conformidade disponível para revisão.
Nenhuma página de padrões deve ser interpretada como declaração universal de conformidade para todos os produtos, tenants, tipos de credenciais ou ambientes UbID.
Governança de versões e perfis
Um deployment interoperável deve registrar:
- versão exata da especificação ou perfil;
- recursos obrigatórios e opcionais suportados;
- formatos de credenciais e algoritmos permitidos;
- requisitos de metadados e discovery;
- comportamento de erro e repetição;
- regras de privacidade e retenção;
- testes de conformidade e limitações conhecidas;
- política de migração e deprecação.
Essa abordagem baseada em perfis permite que a UbID evolua sem alterar silenciosamente o contrato de confiança entre emissores, titulares, Wallets, verificadores e parceiros.
O que os padrões não substituem
Padrões abertos não determinam se uma instituição está autorizada a emitir um claim, se o proofing foi suficiente, se a solicitação do verificador é proporcional, se uma credencial deve ser aceita para uma transação ou se o tratamento é legal em uma jurisdição.
Essas decisões permanecem com a governança, a política, o assurance e os atores institucionais responsáveis.
Limite da documentação pública
O portal público explica padrões, funções, conceitos de ciclo de vida e posições aprovadas de interoperabilidade. Ele exclui schemas privados, perfis de clientes, inventários de endpoints, registros de clientes, trust lists, identificadores de chaves criptográficas, routing de recuperação, extensões internas de protocolos, lacunas de conformidade e credenciais operacionais.
Continue com Identificadores descentralizados, Credenciais verificáveis e SD-JWT ou OpenID para credenciais verificáveis.