Résumé

  • Entre les projets du 1er et du 24 octobre, W3C a retiré de la liaison HTTP(S) le déréférencement des URL DID et la classe de conformité du déréférenceur en réseau. La version du 26 octobre reprend ce choix.
  • La résolution d'un DID garde sa liaison HTTPS. Le choix du résolveur, du traitement de la réponse et de la ressource finale se joue dans le client.

Un service peut répondre impeccablement à une requête DID, avec un code HTTP bien sage et un document en main. Puis l'application demande la clé désignée par #key-1. Le serveur a livré l'enveloppe ; quelqu'un doit encore lire l'adresse à l'intérieur.

La version du 1er octobre de DID Resolution plaçait le déréférencement dans sa liaison HTTP(S). Elle décrivait même un « déréférenceur d'URL DID en réseau » conforme, avec des exemples de requêtes. Le projet du 24 octobre retire cette catégorie ainsi que les exemples. Celui du 26 octobre confirme, jusque dans sa définition OpenAPI, la nouvelle frontière.

La liaison réseau continue de couvrir la résolution du DID. Le texte demande aux résolveurs conformes de prendre en charge GET sur HTTPS ; POST reste facultatif. Le résultat peut apporter le document DID et ses métadonnées. C'est une fonction bien définie, précieuse pour les applications qui ont besoin de retrouver un identifiant.

La suite dépend de l'URL entière. L'algorithme de déréférencement du projet demande au client de permettre le choix d'un résolveur par méthode DID, puis de choisir une stratégie de traitement et d'appeler le bon gestionnaire. Les exemples réservent au client l'interprétation du fragment. Avec un paramètre de service, le chemin vers la ressource prend encore une autre tournure. Le contexte de l'application donne son sens à cette dernière opération.

Ce découpage se voit dans les essais. Un test du seul point d'accès HTTP vérifie une réponse de résolution. Un essai de l'URL complète doit aussi observer la sélection du gestionnaire et le résultat obtenu. Une question ouverte dans le dépôt W3C avait relevé dès mars que le traitement des fragments aboutit côté client. Le compte rendu du 15 octobre montre que le groupe discute encore du lien entre algorithme abstrait et interface concrète pour les tests.

Le déréférencement figure toujours parmi les fonctions « à risque » de cette Candidate Recommendation. Pour suivre le dossier, il faut donc regarder les deux sorties : le document fourni par le résolveur et la ressource finalement utilisée par le client. Une belle réponse à mi-parcours mérite un second ticket de contrôle.