Integração de Wallet e titular

Uma Wallet ou serviço do titular é o limite de confiança voltado à pessoa para receber, proteger, compreender e apresentar credenciais. Deve apoiar o controle individual sem colocar todo o ônus de segurança e recuperação sobre a pessoa.

Responsabilidades da Wallet

Uma integração conforme deve fornecer controles claros para:

• receber credenciais de fluxos de emissão reconhecidos;
• exibir emissor, tipo, validade e status;
• proteger credencial e material de chaves do titular;
• revisar solicitações antes da apresentação;
• selecionar somente os claims necessários;
• criar apresentações recentes e vinculadas à audiência;
• gerenciar dispositivos e sessões;
• suportar backup, continuidade e recuperação protegida;
• exportar ou migrar credenciais suportadas quando a política permitir;
• comunicar falhas e mudanças de ciclo de vida de forma compreensível.

A Wallet não deve divulgar silenciosamente credenciais não relacionadas, inventários completos ou identificadores estáveis entre partes confiantes diferentes.

Recebimento de credenciais

Durante a emissão, a Wallet deve validar contexto suficiente para proteger o titular:

1. identificar emissor e credencial oferecida;
2. confirmar que a transação está atual e destinada à interação;
3. exibir condições materiais e ação solicitada;
4. provar controle da chave exigida sem expor material privado;
5. receber e validar o formato;
6. armazenar a credencial no contêiner protegido aprovado;
7. confirmar o resultado da entrega sem revelar estado não relacionado da Wallet.

A Wallet pode verificar consistência técnica, mas não substitui a responsabilidade do emissor pela verdade dos claims nem a política posterior do verificador.

Custódia protegida

A segurança da Wallet deve distinguir:

• payloads de credenciais;
• chaves do titular e material de binding;
• estado de sessão da aplicação;
• estado de registro de dispositivos;
• material de recuperação;
• índices e metadados visíveis ao usuário;
• backups e estado criptografado sincronizado.

Esses elementos podem exigir controles diferentes de proteção, retenção, migração e exclusão. A documentação pública descreve o modelo, não o formato exato do envelope, parâmetros de derivação, recovery shares ou segredos de dispositivos.

Autorização do titular e revisão da apresentação

Antes da apresentação, o titular deve compreender:

• qual organização solicita evidência;
• finalidade declarada;
• qual credencial ou tipo de evidência é aceitável;
• quais claims serão divulgados;
• se nova prova do titular é necessária;
• por quanto tempo a solicitação permanece válida;
• se a parte confiante pretende reter comprovante;
• como cancelar ou recusar.

A autorização deve ser específica da transação. Uma apresentação anterior não deve tornar-se permissão permanente para solicitações futuras não relacionadas.

Criação da apresentação

O fluxo deve:

1. autenticar solicitação e contexto da parte confiante;
2. comparar a solicitação com credenciais compatíveis;
3. aplicar política da Wallet e do titular;
4. obter autorização informada;
5. criar somente as disclosures exigidas;
6. vincular resposta a audiência, nonce, transação e tempo;
7. adicionar prova do titular quando exigida;
8. transmitir por canal protegido aprovado;
9. mostrar resultado claro ao titular.

A Wallet não decide se a parte confiante concede acesso, elegibilidade, onboarding ou outro resultado institucional.

Ciclo de vida dos dispositivos

A continuidade multidispositivo exige estados explícitos. A integração pode suportar:

• cadastro de novo dispositivo aprovado;
• verificação step-up para registro sensível;
• visibilidade de dispositivos registrados;
• revogação de dispositivo perdido ou comprometido;
• transferência ou sincronização de estado criptografado;
• separação entre dispositivos ativos, pendentes, suspensos e retirados;
• evidência de eventos de ciclo de vida.

Novo dispositivo não deve receber automaticamente toda credencial ou capacidade de recuperação apenas porque o usuário se autenticou uma vez.

Autenticação e sessões

O acesso à Wallet pode usar passkeys, biometria aprovada, device binding ou outros métodos controlados por política. Autenticação estabelece acesso à sessão; não comprova validade de toda credencial nem autoriza toda apresentação.

Operações de alto impacto podem exigir step-up, presença recente ou aprovação adicional. Métodos de fallback devem ser limitados, breves e mais restritos que o acesso normal.

Backup, continuidade e recuperação

O controle do titular não é prático se um dispositivo perdido causa exclusão permanente. A continuidade deve ser projetada antes do lançamento.

Uma recuperação protegida deve separar:

• solicitação e iniciação;
• assurance de identidade e dispositivo;
• autorização;
• preparação de material protegido;
• liberação por threshold ou custodiantes;
• restauração em dispositivo aprovado;
• rotação imediata e invalidação do acesso anterior;
• evidência e notificação ao usuário.

Nenhuma aplicação, operador de suporte ou custodiante deve possuir segredo universal de recuperação.

Portabilidade e interoperabilidade

Uma Wallet deve suportar padrões e perfis aprovados para que credenciais não fiquem confinadas a uma aplicação proprietária. A portabilidade permanece sujeita a formato, política do emissor, holder binding, status e capacidades da Wallet receptora.

Exportação não deve expor chaves privadas nem contornar regras de assurance. Migração pode exigir re-binding, reemissão ou transferência controlada, e não cópia bruta de arquivos.

Acessibilidade e controle informado

O controle do titular exige opções utilizáveis. Os fluxos devem considerar:

• linguagem clara e não técnica;
• apresentação multilíngue quando necessário;
• caminhos acessíveis de autorização e recuperação;
• alternativas quando biometria não é apropriada;
• tratamento seguro de fluxos interrompidos ou abandonados;
• mensagens de status e erro compreensíveis;
• suporte que não contorne política de segurança.

Checklist de readiness da Wallet

Antes da produção, confirmar que:

• perfis de recebimento e apresentação estão fixados;
• material privado permanece sob proteção aprovada do titular;
• autenticidade da solicitação e binding transacional são aplicados;
• o titular pode inspecionar e limitar disclosures;
• cadastro e revogação de dispositivos são operacionais;
• recuperação restaura controle sem segredo universal de administrador;
• portabilidade está documentada corretamente;
• acessibilidade e alternativas não biométricas foram consideradas;
• passam testes de perda, replay, sessão comprometida e recuperação falha;
• suporte não pode ignorar autorização nem proteção de chaves.

Limite da documentação pública

Esta página não publica formatos de envelopes, parâmetros de derivação, segredos de dispositivos, distribuição de recovery shares, topologia de sincronização, limiares biométricos, tokens de sessão ou configuração de produção da Wallet.

Consulte UbID Wallet, Autenticação e segurança de dispositivos e Recuperação e continuidade.