Resumo

  • O texto de 1º de outubro do W3C descrevia um desreferenciador de URL DID em rede e exemplos na vinculação HTTP(S). As versões de 24 e 26 de outubro retiram essa parte e mantêm a resolução de DIDs por HTTPS.
  • Cabe ao cliente escolher o resolvedor, receber o documento DID e executar a etapa que transforma a URL completa no recurso usado pela aplicação.

Uma aplicação que verifica uma credencial precisa da chave indicada por #key-1. O servidor devolve o documento de did:example:123 e um HTTP 200. A aplicação ainda tem de localizar a chave e aplicá-la no contexto certo. O carimbo de entrega não verifica a credencial.

O rascunho de 1º de outubro de DID Resolution dava ao desreferenciador em rede uma classe de conformidade. A vinculação HTTP(S) e seus exemplos atendiam tanto à resolução quanto à desreferenciação. Na versão de 24 de outubro, essa segunda função saiu da vinculação e a classe desapareceu. A publicação de 26 de outubro registra a mesma retirada também na definição OpenAPI.

O resolvedor continua com uma porta de rede especificada. O texto exige GET sobre HTTPS dos resolvedores conformes e admite POST como opção. A resposta entrega o documento DID e metadados. Para um produto que depende de vários métodos DID, essa interface comum ainda tem valor: estabelece como pedir a matéria-prima.

O trabalho seguinte tem outro dono. O algoritmo de desreferenciação manda o cliente permitir que o usuário escolha resolvedores por método, examine o resultado e invoque o tratamento cabível. Nos exemplos do próprio W3C, o fragmento fica do lado do cliente. Uma URL com parâmetro de serviço exige seleção e tratamento do serviço correspondente. A aplicação conhece a finalidade da consulta e decide como usar a resposta.

O tema já estava na mesa em março, quando a questão 306 do grupo apontou o limite do serviço remoto diante dos fragmentos. A ata de 15 de outubro mostra a discussão sobre testar algoritmos abstratos com interfaces concretas. Para uma equipe compradora, a consequência é simples: pedir dois resultados de ensaio. Primeiro, o documento devolvido pelo resolvedor. Depois, o recurso efetivamente obtido ao processar a URL inteira.

A desreferenciação segue marcada como função sujeita a mudanças nesta fase de Candidate Recommendation. Enquanto o desenho amadurece, vale separar duas linhas no relatório de falhas: o documento que o resolvedor devolveu e a chave que o aplicativo realmente usou. Se a primeira linha estiver verde e a segunda falhar, já se sabe onde procurar.