Qu’est-ce que Hyperledger Aries?
Le projet Hyperledger Aries (en anglais seulement) est un ensemble de composants logiciels libres visant à permettre l’utilisation de justificatifs vérifiables. Hyperledger Aries Cloud Agent-Python (ACA-Py) est à la fois le précurseur et la référence en termes d’implémentation. Cependant, ce n’est pas la seule implémentation. Il en existe plusieurs et il est probable que leur nombre continue d’augmenter à mesure que les justificatifs vérifiables évolueront.
Le problème est qu’il n’est pas garanti que les implémentations puissent communiquer entre elles, même si elles sont censées être compatibles dès leur conception. La compatibilité prévue doit toujours être testée de manière approfondie. Sinon, par exemple, une personne disposant d’un justificatif vérifiable par le biais d’une implémentation peut ne pas être en mesure d’utiliser son justificatif vérifiable avec un vérificateur fonctionnant sur une autre implémentation. D’où l’importance des tests, qui sont au centre du projet d’amélioration du harnais de test des agents Aries (HTAA).
Pour permettre l’interopérabilité dans l’écosystème des justificatifs vérifiables Aries, un certain nombre de standards sont définis sous la forme de demandes de commentaires (Request for Comments ou RFCs – en anglais seulement). Ces RFCs sont regroupées en profils d’interopérabilité Aries (Aries Interop Profiles ou AIP – en anglais seulement). Ces profils, à leur tour, définissent le groupe de RFCs auquel un agent doit se conformer, afin d’être identifié comme étant conforme au profil d’interopérabilité Aries. Bien que les conceptions ou les implémentations pourraient être conformes sur papier, lorsque l’implémentation est soumise au test d’interaction avec d’autres implémentations, cela ne fonctionne pas toujours. Ceci peut être dû à des bogues d’implémentation ou des interprétations incohérentes des RFCs. La détection précoce de ces lacunes était, et reste nécessaire pour contribuer à atteindre l’interopérabilité générale de l’écosystème.
Ainsi, le projet du HTAA a été lancé en novembre 2019 sous la forme d’un simple serveur mandataire. Cependant, il a évolué pour devenir un cadre de test axé sur le comportement, utilisé régulièrement par les développeurs et les intégrateurs de la communauté.
Maintenant que plusieurs implémentations des RFCs pour Aries existent, dans plusieurs langages, le HTAA permet de les tester de différentes manières, des simples tests de régression utilisés par les développeurs de la communauté Aries, aux résultats d’interopérabilité (en anglais seulement) régulièrement publiés.
La possibilité de tester facilement un agent compatible avec Aries à l’aide du HTAA permet de découvrir rapidement les bogues et, surtout, les problèmes d’interopérabilité tels que les interprétations incohérentes des RFCs, les choix de conception ou d’implémentation. C’est un atout pour toute équipe de développement et tout projet.
L’approche du projet d’amélioration du harnais de test des agents Aries
Actuellement, deux profils AIP sont définis : AIP 1.0 et 2.0. AIP v2.0 s’appuie sur le succès d’AIP v1.0 en introduisant des fonctionnalités plus robustes et améliorées (en anglais seulement). Lorsque les participants ont commencé à mettre en place ces nouvelles fonctionnalités dans leurs agents, il est devenu évident que le HTAA devait également être amélioré pour soutenir la communauté, éliminer toute ambiguïté dans les RFCs et démontrer ces nouvelles capacités dans de multiples implémentations. Cependant, le soutien d’AIP 2.0 n’a pas été complètement mis en place dans le HTAA.
C’est ici qu’IDLab, soutenu par Interac, a vu le besoin d’aider la communauté en améliorant le HTAA du point de vue d’AIP 2.0.
À ce stade du projet d’amélioration du HTAA, deux facteurs ont contribué à définir son contenu général :
- l’écart entre les RFCs constituant AIP 2.0 et l’implémentation actuelle des tests du HTAA
- les exigences d’Interac concernant AIP 2.0
Ce contenu a été essentiellement exprimé en termes de RFCs et de protocoles Aries, qui n’ont été que partiellement testés, ou pas du tout testés, ou pour lesquels une implémentation de référence n’existe peut-être pas encore.
Les discussions avec les experts de la communauté Aries et la durée convenue du projet ont permis de réduire le nombre de fonctionnalités pour définir le contenu du projet. Des experts de la société Animo (en anglais seulement) ont été invités pour la mise en œuvre du projet.
Leçons apprises
La mise en place du projet d’amélioration du HTAA s’est déroulée en grande partie comme prévu. Cependant, l’étude du code a mené à quelques découvertes importantes.
Le projet du HTAA ne semble pas si volumineux, avec environ 13 000 lignes de code. Cependant, sa complexité réside dans son architecture et dans le fait qu’il vise à lancer et à vérifier des cas d’utilisation réels de l’identité numérique avec des interactions réelles entre agents et portefeuilles mobiles. Par conséquent, il fait appel à beaucoup plus de code que ses 13 000 lignes, en raison de l’explosion combinatoire des tests de sept implémentations – et plus – les unes par rapport aux autres. Ce phénomène est multiplié par la complexité croissante des cas de test et des protocoles disponibles.
Ainsi, l’ajout et le complément de fonctionnalités ont nécessité le règlement de certaines dettes techniques, non seulement pour rationaliser la mise en place du projet en cours, mais aussi pour les futurs utilisateurs. En d’autres termes, un certain travail a été nécessaire pour s’assurer que l’ajout de plus de cas de test n’augmentera pas exponentiellement la complexité.
De plus, certains tests pour le profil AIP 2.0 n’ont pas été mis en place, pour une bonne raison : les fonctionnalités correspondantes étaient absentes de la plupart des implémentations des agents. Par conséquent, la portée de la base de code du projet a dû être étendue en dehors du HTAA pour englober au moins ACA-Py et Aries Framework JavaScript, qui est la contrepartie JavaScript d’ACA-Py. Pour les autres implémentations d’agents Aries qui n’ont pas pu être améliorées directement, les problèmes ont été signalés afin que la communauté puisse récupérer les fonctionnalités pertinentes.
L’expertise technique a dû être recherchée auprès des architectes et des mainteneurs d’Aries au sein de la communauté, car certaines implémentations s’écartaient, voire contredisaient, quelques RFCs. Des corrections ont dû être apportées soit au code, soit aux RFCs elles-mêmes lorsqu’elles ne correspondaient pas à la réalité des implémentations.
Prochaines étapes
Ce projet a été salué par la communauté parce qu’il a permis de grandes avancées pour la mise en place d’AIP 2.0, mais la mise en place complète d’AIP 2.0 n’est pas encore terminée. Les progrès d’AIP 2.0 seront nécessairement pris en compte dans les futurs projets d’amélioration du HTAA.
Le test des portefeuilles mobiles est une autre lacune qui a été soulignée lors de l’examen du projet. Avec l’adoption croissante de l’identité numérique, particulièrement au Canada, les portefeuilles mobiles – également appelés agents mobiles – prennent de plus en plus d’importance. Les justificatifs vérifiables pour les organisations et les personnes ne peuvent fonctionner sans accès aux portefeuilles numériques, que ce soit sur des appareils intelligents ou des ordinateurs. À l’heure actuelle, une petite partie du HTAA est consacrée aux tests des appareils mobiles, ce qui pourrait certainement être amélioré.
