O formulário foi enviado com sucesso.
Encontrará mais informações na sua caixa de correio.
Contrate-nosSelecionar a língua
Sobre nós
ServiçosTecnologiasIndústriasCarteira
Provavelmente, já o viu: dê uma selfie ao GPT, peça um documento tipo passaporte e, em poucos minutos, obtém algo que pode passar nos controlos visuais básicos. Se acrescentarmos a clonagem de voz e o vídeo sintético, a “vivacidade” começa a parecer um teatro. Esta é a verdadeira rutura na identidade digital em 2026. O próprio modelo KYC baseado em fotografias está a ficar desgastado. Se a prova de identidade ainda depende de imagens difíceis de falsificar, estamos a construir sobre areia.
Onde é que isso nos deixa? Com uma mudança bastante óbvia: deixar de armazenar dados de identidade e passar a verificar os pedidos criptograficamente. Em vez de recolher uma digitalização do passaporte e colocá-la noutra base de dados, o sistema pede provas: tem mais de 18 anos, foi aprovado no KYC, tem autorização para esta transação e pode prová-lo sem revelar mais nada?
Mas o que é que muda exatamente? Porque é que de repente estamos a falar de DIDs e de credenciais verificáveis?
Porque num modelo baseado no DID, a confiança não vem do aspeto de algo. Depende de quem o assinou e se pode provar que tem controlo sobre ele. Uma selfie falsa não ajuda se o verificador espera uma credencial assinada por um emissor de confiança e ligada às suas chaves criptográficas. Já não está a tentar “parecer real”. Está a provar a posse de uma reivindicação válida e assinada. As imagens deixam de ser a fonte de confiança. As assinaturas assumem o controlo.
E é esse o objetivo deste guia: Vou mostrar como funciona esse modelo, porque é que se está a tornar o caminho mais sério e onde é que a cadeia de blocos se encaixa nele.
Um identificador descentralizado, ou DID, é um identificador baseado em URI concebido para ser controlado através de chaves criptográficas em vez de ser emitido e gerido por um diretório central. No âmbito do Consórcio da World Wide Web (W3C) De acordo com a norma DID, um DID é resolvido por um documento DID que informa outros sistemas sobre como verificar assinaturas, autenticar o controlador ou descobrir pontos finais de serviço associados a esse identificador. Em termos simples: um DID não é o seu perfil, o seu passaporte ou o registo da sua conta. É o indicador que as outras partes utilizam para verificar se controla um identificador específico e as chaves que lhe estão subjacentes.
É nesta altura que as pessoas muitas vezes achatam tudo e dizem que é “apenas mais uma identificação”. Não é.
Um endereço de correio eletrónico é realmente um localizador dentro do sistema de outra pessoa. Se o fornecedor suspender a conta, o identificador desaparece efetivamente. Um SSN é um identificador emitido pelo Estado, mas não tem uma camada de prova criptográfica incorporada; qualquer pessoa que obtenha o número pode reproduzi-lo. Os tokens OAuth são novamente diferentes: não são identificadores de identidade, mas artefactos de acesso delegado emitidos por um servidor de autorização para que um cliente possa chamar um recurso protegido. Útil, sim. Camada de identidade portátil, não.
Um DID funciona de forma diferente. O objetivo é ser resolvido e não apenas procurado numa base de dados de fornecedores. O controlo cabe ao sujeito através de material-chave e das regras do método DID, e não a um fornecedor de correio, plataforma SaaS ou corretor de identidade. Esta distinção é importante na prática. Se você estiver criando credenciais reutilizáveis, login baseado em carteira ou fluxos de verificador que devem funcionar além das fronteiras organizacionais, um e-mail ou ID de usuário específico do aplicativo não terá semântica de confiança suficiente. Um DID pode.
Ao nível da sintaxe, o modelo W3C é simples: um DID tem três partes: o esquema DID, um nome de método e um identificador específico de método. Por outras palavras: did:método:identificador.
Tomar did:web:exemplo.com como um exemplo concreto.
Com did:web, A resolução, normalmente, mapeia para um documento DID publicado numa localização HTTPS bem conhecida nesse domínio. Com algo como did:ethr, A resolução depende das regras do método ligado ao Ethereum. Mesma sintaxe DID, modelo de confiança e de atualização diferente.
Este é o ponto-chave: a cadeia DID em si é apenas o identificador. O método diz-lhe como o resolver. O documento DID fornece-lhe o material de verificação. Assim que o obtiver, pode verificar assinaturas, autenticar um titular ou validar uma apresentação de credenciais sem tratar o identificador como apenas mais uma linha na tabela de utilizadores de alguém.
Até agora, considerámos as DID e as credenciais verificáveis como estruturas de dados: identificadores, documentos, assinaturas. Mas isso é apenas parte de um sistema de identidade funcional. Em implementações reais, o problema mais difícil é a interação: como as credenciais são emitidas, como são apresentadas e como os verificadores decidem se confiam nelas.
Em sistemas de produção como o Carteira de identidade digital da UE ou Carta de condução móvel dos EUA (mDL) Os pilotos, carteiras e verificadores não se limitam a “resolver uma DID” e ficam por aí. Comunicam através de protocolos definidos e formatos de credenciais:
A distinção importante é que os DID e as credenciais verificáveis definem o que está a ser verificado. Estes protocolos definem como se move entre o emissor, o titular e o verificador em sistemas reais.
Sem esta camada, os DID continuam a ser um mecanismo de resolução. Com ela, passam a fazer parte de uma infraestrutura de identidade funcional.
Se a analisarmos em pormenor, a identidade descentralizada é um modelo em que os identificadores, as credenciais e os fluxos de verificação não são controlados por um único fornecedor. Em vez disso, a identidade é ancorada em chaves criptográficas (através de DIDs), e as reivindicações sobre essa identidade são emitidas e verificadas independentemente do local onde são utilizadas. Uma maneira útil de pensar sobre isso: a identidade deixa de ser uma conta armazenada na base de dados de outra pessoa e passa a ser um conjunto de declarações verificáveis que pode controlar e reutilizar.
Vamos comparar isso com os modelos com que já está a trabalhar.
A identidade centralizada continua a ser a predefinição em todo o lado. Uma plataforma detém o registo do utilizador, armazena os seus dados e actua como autoridade de verificação. Se quiser ter acesso, o utilizador autentica-se nesse sistema. Tudo, incluindo o início de sessão, as permissões e a recuperação, passa por ele.
O problema não é apenas a segurança (embora as violações sejam uma questão constante). É a arquitetura:
A identidade descentralizada inverte esta situação. O sistema não precisa de armazenar os seus dados. Só precisa de verificar as afirmações que apresenta. A confiança passa de “temos os seus dados” para “podemos verificar esta prova criptográfica”.”
A identidade federada (OAuth, SAML, OpenID Connect) tentou resolver a fragmentação através da introdução de fornecedores de identidade, como a Google, a Microsoft ou a Apple, que garantem a identidade dos utilizadores em todos os serviços.
Funciona, até certo ponto. Mas a identidade federada continua a ter uma dependência central:
A identidade descentralizada elimina essa dependência. Não há um único emissor que deve estar online no momento da verificação. As credenciais são verificadas por meio de assinaturas, não por chamadas de API. Isso significa que:
É mais parecido com o funcionamento das credenciais físicas: não se telefona para o serviço de passaportes sempre que alguém verifica o seu BI.
Estes termos confundem-se muito. SSI é mais uma filosofia de design: o indivíduo controla a sua identidade, escolhe o que partilhar e não está preso a um fornecedor. A identidade descentralizada é a pilha técnica que torna isso possível:
É possível implementar sistemas de identidade descentralizados que não sejam totalmente “auto-soberanos” (por exemplo, carteiras controladas pela empresa ou redes com permissões). E pode falar-se de SSI sem especificar a infraestrutura. Em sistemas reais, os dois geralmente convergem, mas é útil manter a distinção clara quando se está a projetar arquitecturas.
As carteiras são onde a identidade descentralizada se encontra com as restrições do mundo real. Em teoria, o controlo da identidade provém do controlo das chaves criptográficas. Na prática, isso cria um problema que os sistemas tradicionais não têm: o que acontece quando o utilizador perde o acesso?
Se um DID estiver associado a uma chave privada e essa chave se perder, não existe um mecanismo de recuperação predefinido. Não existe um fluxo de “repor a palavra-passe”, a menos que o sistema esteja explicitamente concebido para o suportar. A perda da chave pode significar a perda de controlo sobre o identificador e as credenciais a ele associadas.
É por isso que os sistemas de produção introduzem modelos de recuperação e custódia no topo da camada DID:
O compromisso é inevitável: quanto mais o controlo é transferido para o utilizador, mais a responsabilidade é transferida para a gestão de chaves. É por isso que a maioria das implementações no mundo real equilibra a auto-soberania com a usabilidade, em vez de transferir toda a propriedade da chave para o utilizador.
Vale a pena fazer uma pausa aqui, porque a identidade baseada em DID só se torna realmente evidente quando se separam os seus principais elementos. O identificador não é a credencial, a credencial não é a carteira e o marcador na cadeia não é a própria identidade. Cada camada tem uma função distinta, e essa separação é o que faz o modelo funcionar.
Estes dois componentes formam o núcleo do modelo de identidade descentralizado. Nalguns sistemas, especialmente em ambientes Web3, são utilizados mecanismos adicionais na cadeia para reforçar o acesso ou as funções.
Fichas de alma presa (SBTs) são um exemplo. São tokens intransmissíveis ligados a uma carteira e utilizados para coisas como a certificação KYC, a acreditação ou as permissões de protocolo. Os contratos inteligentes podem verificá-los diretamente.
No entanto, os SBT não fazem parte da pilha de identidade propriamente dita. São uma camada de aplicação opcional construída em cima de sinais de identidade, e vêm com compensações: visibilidade pública na cadeia, portabilidade limitada e desafios em torno da revogação e recuperação de chaves.
Os sistemas de identidade tradicionais falham porque tratam a confiança como um problema de armazenamento. Todas as plataformas recolhem as mesmas provas em bruto, como digitalizações de passaportes, selfies e comprovativos de morada, e depois armazenam-nas dentro do seu próprio perímetro de conformidade. Isto cria a mesma confusão em todo o lado: PII duplicadas, fraca portabilidade, amplas superfícies de violação e fluxos de integração que se tornam mais pesados sem melhorarem muito.
No modelo tradicional, os sistemas de identidade acumulam riscos ao longo do tempo. Os fornecedores de KYC, as bolsas de valores, as aplicações fintech, as plataformas de RH e os mercados acabam por armazenar praticamente o mesmo conjunto de provas: identificação do governo, digitalização facial, dados de endereço e metadados da própria sessão de verificação.
Do ponto de vista da implementação, o problema é normalmente agravado pela proliferação de cópias. Os mesmos dados de utilizador acabam em sistemas de integração, ferramentas de fraude, camadas de CRM, ferramentas de suporte, armazéns de dados e arquivos de conformidade. Mesmo que a pilha de verificação primária esteja bloqueada, os sistemas circundantes muitas vezes não são mantidos com o mesmo padrão.
A identidade tradicional não dá ao utilizador quase nenhum controlo sobre o estado de verificação. A plataforma controla o registo, a política de retenção, o calendário de re-verificação e as regras de reutilização.
Isto significa que o utilizador não pode transportar a confiança de um contexto para outro. A aprovação do KYC na plataforma A não faz nada na plataforma B porque o resultado da verificação está preso dentro do perímetro de conformidade da plataforma A. A declaração subjacente pode ainda ser válida, mas não existe um artefacto criptográfico portátil em que o verificador seguinte possa confiar.
É aqui que o modelo começa a falhar em termos económicos. Todas as plataformas pagam para reconstruir a confiança a partir do zero, porque a identidade é armazenada como dados internos e não emitida como prova reutilizável.
O modelo antigo também revela demasiado por defeito. Para provar um facto restrito, é normalmente pedido aos utilizadores que revelem o documento de origem completo que lhe está subjacente.
Este é um mau padrão de privacidade, mas é também um mau padrão de sistema. Quando a identidade está ligada a registos baseados em contas e à apresentação repetida de documentos, a correlação torna-se fácil entre serviços, sessões e contrapartes. O verificador obtém mais dados do que precisa, armazena mais do que deveria e aumenta a responsabilidade sem melhorar proporcionalmente a qualidade da confiança.
Este é o imposto operacional que toda a gente já conhece. A mesma pessoa completa o KYC várias vezes porque cada plataforma executa sua própria pilha de confiança e não pode consumir a verificação como uma credencial portátil.
Se já trabalhou em tokenização, integração de câmbios ou fluxos de carteiras regulamentadas, já viu como isto é um desperdício. O gargalo é o facto de a confiança não se poder mover de forma limpa entre sistemas, pelo que cada instituição reconstrói o mesmo pipeline de verificação em torno do seu próprio limite de base de dados.
E mesmo as credenciais verificáveis não resolvem isso por si só. Uma assinatura válida apenas prova que uma reivindicação foi emitida por uma parte específica. Não prova que essa parte tinha autoridade para emitir esse pedido. Esta é a parte que muitos pilotos de DID subestimam. Os verificadores precisam de saber que emissores são legítimos, que esquemas de credenciais são aceites e ao abrigo de que regras se pode confiar numa reivindicação.
Na produção, isto é tratado através de estruturas de confiança: eIDAS 2.0 listas de confiança na UE, Estilo VICAL coordenação da confiança para cartas de condução móveis ao abrigo da norma ISO 18013-5, Federação OpenID cadeias de confiança e registos nacionais de prestadores de serviços de confiança.
Sem essa camada, não se obtém uma identidade reutilizável. Obtém-se credenciais que são verificadas matematicamente mas que não significam nada em termos operacionais. A assinatura é válida. Falta a confiança.
"Porque é que o modelo de identidade descentralizada funciona? Porque dá a cada parte menos para armazenar, menos para expor e menos para verificar novamente. O utilizador reutiliza a prova de confiança, o verificador obtém apenas a declaração de que necessita e a plataforma evita tornar-se outro cofre de PII. No Innowise, isso geralmente significa credenciais fora da cadeia para portabilidade, atestados na cadeia para controlo de acesso e divulgação selectiva para verificações sensíveis à privacidade."
Especialista em cadeias de blocos e analista de DeFi
Já chega de definições. O que importa aqui é o caminho da verificação: como um DID se torna resolúvel, como um emissor vincula uma reivindicação ao mesmo e como essa reivindicação é verificada posteriormente sem recorrer a um registo central. Vamos percorrer o fluxo de ponta a ponta.
Um DID só se torna útil quando pode ser resolvido. É gerado com material-chave e publicado de acordo com um método DID. A resolução devolve o documento DID, que expõe as chaves públicas e os métodos de verificação que outros utilizam para validar assinaturas.
Uma vez que o sujeito tem um DID, um emissor pode anexar uma reivindicação assinada a ele como uma credencial verificável. O emissor efectua primeiro as suas verificações e, em seguida, assina uma credencial que liga a reivindicação ao identificador da pessoa. O que avança não é uma prova em bruto, mas um resultado atestado.
O titular armazena a credencial, normalmente numa carteira, e apresenta-a quando é necessária uma prova. Dependendo da pilha, pode ser a credencial completa ou uma prova derivada. O objetivo é a reutilização: o titular apresenta uma reivindicação já verificada em vez de reiniciar o onboarding.
O verificador verifica a assinatura do emissor, confirma a vinculação do sujeito e avalia o estado da credencial, como a expiração ou a revogação. Para o efeito, resolve o DID do emitente e recupera a chave pública do documento DID. Não é necessária uma chamada de retorno do emitente.
Um DID só se torna útil quando pode ser resolvido. É gerado com material-chave e publicado de acordo com um método DID. A resolução devolve o documento DID, que expõe as chaves públicas e os métodos de verificação que outros utilizam para validar assinaturas.
Uma vez que o sujeito tem um DID, um emissor pode anexar uma reivindicação assinada a ele como uma credencial verificável. O emissor efectua primeiro as suas verificações e, em seguida, assina uma credencial que liga a reivindicação ao identificador da pessoa. O que avança não é uma prova em bruto, mas um resultado atestado.
O titular armazena a credencial, normalmente numa carteira, e apresenta-a quando é necessária uma prova. Dependendo da pilha, pode ser a credencial completa ou uma prova derivada. O objetivo é a reutilização: o titular apresenta uma reivindicação já verificada em vez de reiniciar o onboarding.
O verificador verifica a assinatura do emissor, confirma a vinculação do sujeito e avalia o estado da credencial, como a expiração ou a revogação. Para o efeito, resolve o DID do emitente e recupera a chave pública do documento DID. Não é necessária uma chamada de retorno do emitente.
Quando o fluxo é claro, surgem as verdadeiras questões de conceção: como os identificadores são utilizados e como as chaves são geridas ao longo do tempo.
Um DID público é estável e detetável. Os emissores utilizam-no normalmente porque os verificadores precisam de uma forma consistente de resolver chaves e validar assinaturas. Por outro lado, uma DID de pares é gerada por relação. O mesmo utilizador apresenta identificadores diferentes a verificadores diferentes, o que impede a correlação entre serviços.
Essa escolha não é cosmética. A reutilização de um único DID em todos os serviços torna a ligação trivial. Os DIDs emparelhados quebram essa ligação ao nível do identificador.
Depois, há a gestão de chaves, que é onde a maioria dos sistemas tem dificuldades na produção. Um DID é tão fiável quanto as chaves que o suportam, pelo que é necessário planear:
Na prática, é aqui que reside a complexidade. A verificação da assinatura é simples. Manter os identificadores utilizáveis, recuperáveis e não-correlacionáveis ao longo do tempo é o problema de engenharia mais difícil.
Uma vez ultrapassado o fluxo, a questão seguinte é a forma como os identificadores são efetivamente resolvidos e mantidos. Isso se resume a duas coisas: a Estrutura do documento DID e a Método DID que define a forma como é criado, atualizado e resolvido.
Um documento DID é a saída de resolução de um DID. Indica aos verificadores que chaves, controladores e pontos finais de serviço estão autorizados para esse identificador. Na prática, não é um perfil de utilizador. É um descritor de verificação.
Domínios fundamentais que normalmente lhe interessam:
E o ponto de implementação da chave permanece o mesmo: um verificador resolve o DID, seleciona o método de verificação adequado e verifica se essa chave está autorizada para a operação que está a ser executada.
Até agora, falámos sobretudo da identidade como algo que uma pessoa controla. Nos sistemas B2B, o assunto principal é frequentemente uma organização. Os bancos, os fornecedores de logística e as plataformas RWA precisam de verificar não só que assinou algo, mas se essa pessoa estava autorizada a agir em nome de uma empresa.
É aqui que as DIDs organizacionais se tornam mais complexas. O controlo é distribuído por funções, sistemas de custódia, políticas de assinatura e regras de delegação. Uma configuração de produção tem de definir quem pode assinar, o que pode assinar e como essa autoridade é revogada.
Na prática, isto pode implicar vLEI da GLEIF para a identificação de entidades jurídicas, carteiras de empresas com Assinatura com suporte HSM, e cadeias de capacidades de autorização, tais como ZCAP-LD.
Os documentos DID não são estáticos. As chaves expiram, os dispositivos perdem-se, as infra-estruturas de assinatura mudam e as chaves do emissor precisam de ser rodadas. Um projeto de DID sério tem de lidar com isto sem quebrar as credenciais existentes.
A rotação de chaves normalmente significa adicionar um novo método de verificação, alterar qual a chave autorizada para uma determinada relação e retirar a chave antiga. Mas o detalhe que importa é objetivo. Rotação de um autenticação afecta os fluxos de início de sessão ou de resposta a desafios. A rotação de uma assertionMethod A chave afecta a emissão e verificação de credenciais.
O caminho de atualização depende do método DID. Com did:web, actualiza-se o documento DID alojado. Com did:ethr, O sistema de registo de credenciais é um sistema de registo de credenciais, que publica uma transação no registo. A parte difícil é a continuidade: os verificadores têm de saber que chave era válida quando uma credencial foi emitida e se essa credencial foi revogada, expirou ou foi substituída.
E isso leva-nos aos métodos DID, porque o método define exatamente como funcionam a criação, a resolução, as actualizações e a desativação no sistema real.
Um método DID é a camada de implementação por detrás da sintaxe DID normalizada.
Define as regras para:
Por outras palavras, a sintaxe DID é padrão (did:método:identificador), mas o método molda todo o modelo de infra-estruturas por detrás do DID.
Estes três métodos abrangem a maioria dos casos de utilização no mundo real:
Agora, o quadro dá-lhe a mecânica. A parte mais difícil é decidir com que modo de falha se pode viver: Dependência do DNS, custo da cadeia, sem rotação, auditabilidade pública ou portabilidade mais fraca. Eis a minha opinião sobre como escolher.
Antes de escolher, faça as perguntas mais feias sobre a produção:
Em implementações reais, é habitual misturar métodos. Os emissores usam frequentemente did:web ou did:ethr; Os titulares utilizam identificadores aos pares ou efémeros. Esta divisão mantém a confiança do emissor estável e reduz o risco de correlação para os utilizadores.
Vamos esclarecer isso logo no início: você não precisa de um blockchain para implementar uma identidade descentralizada. A especificação DID Core do World Wide Web Consortium não exige isso, e muitos sistemas de produção são executados inteiramente fora da cadeia.
Então, porque é que a cadeia de blocos está sequer em discussão? Porque resolve muito bem um problema específico: confiança partilhada sem um proprietário central. Não o armazenamento, não a identidade em si, mas a coordenação em torno das chaves, dos identificadores e do estatuto.
Nos sistemas baseados em DID, a cadeia de blocos actua como um registo público e inviolável. Dependendo do método, pode ser utilizado para:
O ponto-chave: a cadeia de blocos não está a verificar a identidade. Está a fornecer uma ponto de referência comum em que os verificadores podem confiar sem confiar numa única parte.
Por exemplo, com did:ethr, O DID resolve contra dados na cadeia. O verificador confia no estado da cadeia e não na infraestrutura do emissor.
É aqui que muitas implementações de DID correm mal. A cadeia de blocos é útil para o estado partilhado, mas é um local terrível para dados de identidade em bruto. Não se colocam passaportes, dados biométricos, credenciais completas ou registos pessoais na cadeia. Utiliza-se a cadeia para material de prova e dados de coordenação e, em seguida, mantém-se as cargas úteis de identidade sensíveis fora da cadeia.
Uma divisão limpa tem normalmente o seguinte aspeto:
Na cadeia:
Fora da cadeia:
A razão é simples: privacidade e custos. As cadeias de blocos são públicas, permanentes e de atualização dispendiosa. Os dados de identidade necessitam de privacidade, eliminação, correção e controlo de acesso. Essas duas coisas não se misturam.
A cadeia de blocos é normalmente utilizada para ancoragem, não para armazenamento. É possível atribuir uma pequena prova de estado à cadeia, como um hash de um documento DID, uma atualização do registo do emissor, uma referência ao estado da credencial ou um evento de rotação de chaves, enquanto os dados de identidade reais permanecem fora da cadeia.
Isto confere aos verificadores três propriedades úteis:
A contrapartida é a permanência. Se colocarmos os dados errados na cadeia, não os podemos remover de forma limpa. É por isso que os sistemas DID maduros ancoram hashes, referências e transições de estado, e não credenciais completas, documentos ou dados pessoais.
A cadeia de blocos é a ferramenta errada quando não elimina uma dependência de confiança. Se a mesma organização controla o emissor, o verificador e a aplicação, colocar o estado do DID na cadeia normalmente apenas acrescenta taxas, latência e ruído operacional.
Ignorar a cadeia de blocos quando:
É por isso que did:web funciona tão bem para muitos fluxos de identidade empresarial. Mantém o modelo DID, mas utiliza a infraestrutura Web existente em vez de forçar cada atualização através de uma transação de cadeia de blocos.
Utilize a cadeia de blocos quando partes independentes necessitarem de um estado partilhado que possam verificar sem confiar no seu servidor. Caso contrário, mantenha-o fora da cadeia. Mais descentralização no papel não significa automaticamente uma melhor arquitetura de identidade.
Em sistemas como a Carteira de Identidade Digital da UE ou as cartas de condução móveis (ISO 18013-5), a PKI foi escolhida em grande parte porque as redes públicas L1/L2 não cumprem os principais requisitos de identidade: privacidade, soberania dos dados e controlo regulamentar. Os dados de identidade não podem ser replicados publicamente e as jurisdições necessitam de um controlo rigoroso sobre o local onde os dados são processados e armazenados.
Mas as arquitecturas mais recentes introduzem uma terceira opção: sistemas zk-L2 autorizados. Estes combinam:
A ideia-chave é a separação das preocupações a nível das infra-estruturas:
Isto evita uma limitação essencial das cadeias públicas: a exposição dos dados. Ao mesmo tempo, evita uma limitação da PKI pura: a dependência de hierarquias de confiança fechadas sem auditabilidade partilhada.
Outra propriedade importante é arquitetura multi-domínio. Diferentes actores - ministérios, reguladores, bancos ou regiões - podem operar em zonas de execução separadas com os seus próprios limites de conformidade, contribuindo simultaneamente para um estado verificável partilhado através de provas.
Isso expande o espaço de design para sistemas de identidade. Em vez de escolher entre PKI centralizada e blockchain pública, novas implantações podem combinar privacidade, conformidade e confiança compartilhada em um único modelo.
Ok, por esta altura já deve ser claro o que é que as DIDs fazem de diferente do KYC normal. Mas a questão mais prática é: o que é que isso muda realmente para mim? É uma pergunta justa. Pelo que vi em implementações reais, o impacto depende muito do lado em que se está, por isso vale a pena dividi-lo.
Para os utilizadores, a maior mudança é o controlo sobre quando e como a identidade é partilhada.
Na prática, isto faz com que a identidade deixe de ser algo que se reenvia constantemente e passe a ser algo que se presente quando necessário.
Para as organizações, a mudança tem menos a ver com UX e mais com risco e estrutura de custos.
O que muda operacionalmente é o seguinte: deixamos de ser um guardião de dados e passamos a ser um verificador de sinistros.
Para os programadores, o valor está em como a lógica da identidade é estruturada.
Do ponto de vista da engenharia, a mudança é de “gerir utilizadores e sessões” para verificação de provas e imposição de condições.
Vamos deixar de lado a teoria por um segundo e vamos analisar isto como faríamos num sistema real. O que é que o DID faz realmente sentir-se como na prática? Onde é que deixa de ser um diagrama e começa a ser algo que se envia?
Vai reparar numa coisa à medida que avançamos: os objectos mudam - diploma, histórico profissional, estatuto KYC - mas o fluxo quase não muda.
Imagine que acabou de se formar e precisa de provar o seu diploma a um futuro empregador. O caminho habitual é desajeitado: carregar um PDF, anexar uma digitalização, talvez esperar que alguém envie um e-mail para o registo. Funciona, mas por pouco. Todo o processo depende da confiança manual.
Com uma credencial baseada em DID, a universidade emite uma credencial verificável quando se forma. Esta fica na sua carteira, assinada por uma chave publicada no documento DID da universidade.
Meses mais tarde, candidata-se a um emprego. O empregador não precisa de contactar a universidade. Apresenta as credenciais e o sistema verifica-as:
É essa a beleza do modelo: a universidade assina uma vez, reutiliza-se a prova e cada verificador pode verificá-la de forma independente.
Em que parte de um currículo se pode confiar? Os títulos são inflacionados. As datas são confusas. “Liderar uma equipa” pode significar qualquer coisa, desde gerir dez pessoas a gerir standups.
Agora inverta o modelo. Quando se sai de uma empresa, emite-se uma credencial:
Da próxima vez que alguém perguntar: “Podes provar que fizeste X?”, não explicas. Apresenta. E não, isso não significa expor sempre todo o historial profissional. Com o formato de credencial correto, o titular pode provar uma alegação mais restrita, como:
... sem entregar o historial completo de emprego. É uma postura muito diferente de “envie-nos o seu CV completo e referências”.”
Aqui, a identidade reutilizável torna-se óbvia. A verificação é feita uma vez junto de um fornecedor de confiança: passaporte verificado, controlo de sanções aprovado, jurisdição confirmada. O fornecedor emite uma credencial KYC para a sua carteira.
Próxima plataforma? Apresenta as credenciais em vez de voltar a carregar os mesmos documentos. A plataforma verifica:
Algumas equipas de tokenização também utilizam fichas ligadas à alma como marcadores KYC na cadeia: este endereço passou na verificação exigida. Os dados de identidade permanecem fora da cadeia; a cadeia transporta apenas o sinal de elegibilidade.
Útil, mas apenas se o marcador for amplo, revogável e não constituir uma fuga permanente de privacidade.
É nos cuidados de saúde que a arquitetura DID precisa de uma rédea curta. Digamos que uma clínica lhe dá uma credencial de vacinação, um laboratório assina o resultado da sua análise ao sangue e o seu médico emite uma credencial de prescrição. Guarde-as na sua carteira em vez de deixar que cada registo desapareça noutro portal.
Depois muda-se de médico. Esperamos que um sistema fale com outro? Andar atrás de PDFs? Não. Partilha-se a credencial específica de que o novo prestador necessita. Eles verificam o emissor, a assinatura e o estado.
E para que fique claro: nada disto exige que se coloquem dados médicos na cadeia. A cadeia é para identificadores, chaves, talvez registos de estado. As coisas sensíveis ficam fora da cadeia. Se esse limite não for respeitado, a conceção está errada.
Agora vamos afastar-nos das pessoas. Pegue num produto - digamos, uma garrafa de azeite. Rótulo de qualidade, embalagem bonita. Será que é verdadeiro? Em vez de confiar na marca, toca com o seu telemóvel numa etiqueta NFC. Por detrás dessa etiqueta está um DID ligado ao lote do produto.
O que se obtém são dados assinados:
É possível seguir literalmente o produto desde a origem até à prateleira. Resolve tudo? Não. Se a primeira entrada de dados estiver errada, tudo o que vier a seguir apenas preserva o erro. Mas pelo menos agora sabe que assinou cada passo. É um grande avanço em relação ao “confie em nós”.”
É no governo que a identidade de estilo DID deixa a bolha criptográfica. Um ponto de referência importante é a carteira de identidade digital da UE no âmbito do eIDAS 2.0, uma iniciativa em grande escala que visa fornecer carteiras aos cidadãos, residentes e empresas em todos os Estados-Membros.
Mas o panorama mais alargado é mais diversificado. Alguns dos maiores e mais maduros sistemas de identidade digital a nível mundial não se baseiam estritamente em DID, mas seguem padrões semelhantes em torno de credenciais reutilizáveis e dados controlados pelo titular:
A mudança comum a todos estes sistemas é a mesma: passar de registos de identidade centralizados para provas reutilizáveis e apresentadas pelo utilizador. Ao mesmo tempo, é importante separar os modelos de confiança. Sistemas como o eIDAS dependem de PKI federada e listas de serviços de confiança, enquanto os sistemas baseados em DID dependem de identificadores criptográficos e credenciais verificáveis. Na prática, estes modelos coexistem frequentemente em vez de se substituírem uns aos outros.
Até agora, tudo funciona bem dentro de um único sistema. Mas o que acontece quando as credenciais atravessam as fronteiras do sistema? É aí que as coisas se tornam rigorosas. São necessárias normas partilhadas para que os dados façam sentido em todo o lado e é necessária governação para que os verificadores saibam em que emissores devem confiar. Aqui estão as normas e as camadas de governação mais importantes.
As normas tornam as credenciais interoperáveis. A governação torna-as aceitáveis. Sem normas, nada é analisado. Sem governação, nada é fiável. Os sistemas reais só funcionam quando ambas as camadas são definidas em conjunto.
As normas dizem-lhe como um sistema DID se deve comportar. A produção diz-lhe onde é que as coisas se complicam. Atualmente, a maioria dos riscos não advém da sintaxe DID ou dos algoritmos de assinatura em si. Eles surgem em torno das carteiras, da recuperação de chaves, da revogação, da interoperabilidade e do facto de um número suficiente de emissores e verificadores concordarem efetivamente em utilizar o mesmo modelo de confiança.
Nos sistemas DID, a identidade depende do controlo das chaves. É um sistema poderoso, mas implacável. Se um utilizador perder a chave, a recuperação não é automática. Se um atacante obtiver a chave, pode fazer-se passar pelo detentor. É por isso que as implementações sérias raramente dependem apenas de uma frase-semente em bruto. Normalmente, precisam de MPC, recuperação social, chaves apoiadas em hardware ou algum modelo de custódia híbrido.
As credenciais envelhecem. O KYC expira, os funcionários saem, as licenças são suspensas. Por isso, a verificação não se pode limitar a “a assinatura é válida?”. O verificador verifica o estado da credencial no momento da utilização. Normalmente, isso significa listas de estado, registos de revogação ou credenciais de curta duração. Se falhar esta parte, as credenciais antigas continuam a parecer válidas.
As normas ajudam, mas não tornam magicamente compatíveis todas as carteiras, emissores e verificadores. Uma pilha pode usar credenciais JSON-LD, outra pode preferir métodos JWT. Métodos DID. Os protocolos de apresentação são diferentes. Por isso, sim, o ecossistema está a avançar para a interoperabilidade, mas os projectos reais ainda precisam de trabalho de integração e de escolhas de perfil rigorosas.
A parte mais difícil é a coordenação. Um sistema DID precisa de emissores em que as pessoas confiem, verificadores dispostos a aceitar credenciais, utilizadores capazes de gerir carteiras e regras de governação que todos compreendam. Até que essas peças se alinhem, a adoção acontece em bolsos: finanças regulamentadas, tokenização, credenciais de força de trabalho, ID do governo e ecossistemas fechados primeiro.
Atualmente, a maioria dos sistemas DID baseia-se na criptografia de curva elíptica: Ed25519, secp256k1, ou P-256. Estes esquemas são amplamente utilizados, mas não são seguros pós-quânticos. Um computador quântico suficientemente potente poderia quebrá-los com o algoritmo de Shor, tornando a falsificação de assinaturas um risco real a longo prazo.
Isto é importante porque as credenciais de identidade duram muitas vezes anos. Os diplomas, as licenças e os atestados legais emitidos atualmente poderão ter de ser verificados muito depois de a criptografia que lhes está subjacente ter desaparecido.
As normas já estão a avançar nessa direção. O NIST finalizou esquemas de assinatura pós-quântica, como ML-DSA (Dilithium) e SLH-DSA (SPHINCS+), enquanto o ecossistema DID/VC está a explorar assinaturas híbridas e cripto-agilidade.
Os sistemas DID devem suportar vários métodos de verificação, novos conjuntos de assinaturas e caminhos claros de rotação de chaves desde o primeiro dia. As assinaturas pós-quânticas são muito maiores do que as assinaturas Ed25519 ou ECDSA, o que afecta as apresentações QR, os registos e os mecanismos de estado na cadeia. Mas para uma identidade governamental e empresarial de longa duração, a cripto-agilidade é uma necessidade.
O erro que vemos com mais frequência é tratar a DID como algo que se “adiciona” a uma pilha de identidade existente. Na prática, é uma mudança na forma como se modela a confiança, o fluxo de dados e a responsabilidade. As peças técnicas raramente são a parte mais difícil. A maioria dos projetos tem sucesso ou falha na coordenação, governança e integração.
Comece por identificar onde guarda os dados de identidade para os verificar mais tarde: Estado KYC, idade, emprego, licenças, acreditação e direitos de acesso. O objetivo é armazenar menos dados em bruto e verificar mais declarações assinadas. Isso reduz a responsabilidade, simplifica a conformidade e torna a identidade portátil entre sistemas.
Antes de escolher as ferramentas, defina o modelo de confiança em termos concretos. Em projectos reais, isso resulta normalmente em:
Sem isto, obtém-se credenciais que são verificadas corretamente, mas que não são aceites pelos verificadores.
Agora escolha a pilha técnica. Escolha o método DID, o formato da credencial, o fluxo da carteira e o modelo de revogação. did:web normalmente se adapta a fluxos empresariais e SaaS. did:ethr adapta-se à aplicação de contratos inteligentes e à identidade na cadeia. fez:chave se encaixa em identificadores locais ou de curta duração.
Não escolha a opção mais “descentralizada”. Escolha a que corresponde ao seu limite de confiança.
Não comece com “identidade para tudo”. Comece com um fluxo em que a dor seja clara. Bons pilotos incluem:
Definir um âmbito restrito: um tipo de credencial, um ou dois emitentes, um fluxo de verificadores, regras de revogação claras. Evite começar com:
Prove o fluxo de ponta a ponta e depois expanda.
Quando se passa de um projeto-piloto para a produção, a emissão de credenciais é apenas metade do problema. A questão mais difícil é o que acontece quando uma credencial deixa de ser fiável: uma verificação KYC expira, um funcionário sai, uma licença é suspensa ou uma carteira é comprometida.
Não existe uma abordagem padrão única e cada modelo tem as suas contrapartidas:
Os diferentes ecossistemas adoptam abordagens diferentes. Por exemplo, as cartas de condução móveis ISO 18013-5 baseiam-se na validação do emissor e em listas de confiança e não na revogação ao estilo W3C. Sem uma estratégia clara de revogação, o modelo de “credencial reutilizável” não funciona. Uma credencial comprometida pode continuar a ser apresentada, a menos que o seu estado seja ativamente verificado.
Um projeto DID/VC típico desenrola-se por fases. Normalmente, um projeto-piloto demora 3-4 meses e valida um caso de utilização de ponta a ponta, normalmente no intervalo de $150K–$300K, dependendo do âmbito. Uma implementação de produção demora 9-12 meses e expande-se para múltiplos emissores, verificadores e tipos de credenciais, geralmente variando de $800K a $2M+, dependendo da complexidade da integração e dos requisitos de conformidade.
Uma equipa típica inclui:
Na prática, a complexidade raramente está na criptografia. Está na integração, na governação e na experiência do utilizador.
Para concluir, vamos alargar um pouco o horizonte. A identidade baseada em DID não é uma pilha acabada. Ainda está a evoluir, principalmente em torno de sistemas de prova, infraestrutura de carteiras, camadas de interoperabilidade e integração regulamentar. Pelo que vejo em implementações reais, algumas direcções estão a tornar-se claras.
A identidade reutilizável é o objetivo final óbvio, mas o estrangulamento não é a verificação da assinatura. Essa parte já funciona. A parte mais difícil é a confiança do emissor, os esquemas de credenciais e as regras de aceitação.
No futuro, uma credencial KYC emitida num ambiente regulamentado deverá ser reutilizável em bolsas, plataformas de tokenização, produtos de empréstimo e interfaces DeFi compatíveis, desde que o DID do emissor seja resolúvel, o esquema seja compreendido e o verificador aceite o emissor no seu quadro de confiança. É aí que está o verdadeiro trabalho: não provar que uma assinatura é válida, mas chegar a um acordo sobre o que a reivindicação assinada realmente significa.
Atualmente, muitos sistemas ainda revelam atributos. O futuro é provar condições. Em vez de mostrar a data de nascimento, prova-se que se tem mais de 18 anos. Em vez de expor todos os dados KYC, prova que foi aprovado numa política de conformidade definida. Em vez de partilhar um campo de jurisdição, prova-se a elegibilidade para uma transação.
Tecnicamente, isso aponta para assinaturas BBS+ para divulgação selectiva e zk-SNARKs ou zk-STARKs para provas de predicados. O verificador verifica a prova em relação às chaves públicas controladas pelo emissor, enquanto os dados pessoais subjacentes permanecem ocultos. Isto altera o modelo de privacidade de “partilhar menos dados” para “não partilhar os dados de todo quando uma prova é suficiente”.”
A interoperabilidade decidirá se a identidade descentralizada se mantém fragmentada ou se torna uma infraestrutura utilizável.
Os pontos fracos continuam a ser familiares: Credenciais JSON-LD vs JWT, diferentes métodos DID, diferentes protocolos de carteira, diferentes fluxos de apresentação. É por isso que os sistemas de produção definem cada vez mais perfis rigorosos: formatos de credenciais aprovados, métodos DID suportados, emissores de confiança e protocolos de apresentação aceites.
Com o tempo, espero uma maior convergência em torno dos fluxos de carteira para verificador, troca de apresentações e registos de confiança. Sem isso, cada projeto DID torna-se mais uma ilha de identidade. Com isso, as credenciais podem se mover entre plataformas sem integração personalizada todas as vezes.
A regulamentação está a transformar a identidade descentralizada de uma opção técnica numa infraestrutura pública.
Na UE, o eIDAS 2.0 e a carteira de identidade digital da UE são o grande sinal. Os Estados-Membros são obrigados a fornecer a infraestrutura da carteira, com credenciais para atributos de identidade, licenças, qualificações e casos de utilização do sector público-privado. Isto cria uma camada de credenciais regulamentada em toda a Europa.
Nos EUA, o National Institute of Standards and Technology está a atualizar as orientações relativas à identidade digital (p. ex., NIST 800-63) para ter em conta as credenciais criptográficas, os níveis de garantia e a verificação da preservação da privacidade. É provável que os EUA mantenham um modelo mais orientado para o mercado, enquanto a UE promove um quadro coordenado para as carteiras electrónicas.
Então, para onde é que isto vai? Para menos carregamentos de documentos, mais credenciais reutilizáveis, mais verificações criptográficas locais e uma divulgação mais selectiva. Os vencedores não serão os sistemas que armazenam mais dados de identidade. Serão os que conseguirem verificar a alegação correta com o mínimo de exposição.
Um identificador descentralizado é um identificador único e resolúvel que aponta para um documento DID que contém chaves públicas e métodos de verificação. Permite que as entidades provem a sua identidade ou controlo sem dependerem de uma autoridade central. Na prática, substitui as pesquisas na base de dados pela verificação criptográfica.
Um DID é resolvido para um documento DID com chaves públicas. Um emissor assina uma credencial, um titular armazena-a e um verificador verifica a assinatura e o estado utilizando o DID do emissor. Não é necessária uma chamada direta para o emissor. Isto torna a verificação portátil e independente de qualquer sistema individual.
A identidade descentralizada é o modelo geral de emissão e verificação de reivindicações sem armazenamento central. Um DID é apenas um componente desse modelo. Actua como a camada identificadora utilizada para resolver chaves e verificar assinaturas. Sem DIDs, o sistema não teria uma forma consistente de localizar e confiar no material de verificação.
Não necessariamente. Alguns métodos DID utilizam cadeias de blocos para resolução ou ancoragem, mas muitos, como did:web, O DID é uma referência, não um registo de dados. O DID em si é uma referência, não um registo de dados. O que pode ser armazenado na cadeia são chaves, hashes ou referências de estado, não dados de identidade.
São utilizados para ligar identidades a chaves criptográficas, permitir credenciais verificáveis, apoiar KYC reutilizáveis, verificação da força de trabalho, IDs digitais e controlo de acesso em sistemas baseados na Web e em cadeias de blocos. O seu papel é tornar a verificação de identidade portátil entre sistemas.
Gera um par de chaves e cria um DID de acordo com um método escolhido. Em seguida, publica-se ou regista-se para que possa ser resolvido para um documento DID. O processo exato depende do método de DID (por exemplo, web, blockchain ou baseado em chave). O método determina como a DID é ancorada, atualizada e resolvida.
Especialista em cadeias de blocos e analista de DeFi
Andrew traduz conceitos descentralizados em ferramentas financeiras seguras e funcionais. Ele navega no cenário volátil de DeFi para construir infraestruturas de blockchain escaláveis que abordam a utilidade do mundo real, indo além das palavras-chave para fornecer valor técnico.
