Signature des Attestations Vérifiables (Verifiable Credentials) et des Présentations Vérifiables (Verifiable Presentations)
Les Attestations Vérifiables sont signées par leurs émetteurs avant d’être envoyées à leur futur détenteur. Les Présentations Vérifiables (contenant les Attestations Vérifiables) sont signées par leur détenteur avant d’être présentées aux vérificateurs.
L’émetteur transmet donc les Attestations Vérifiables au détenteur qui les stocke dans son portefeuille d’identité, en général une application mobile décentralisée (dApp). Dans un article précédent, nous avions indiqué qu’il était possible d’avoir une carte NFC comme solution d’accompagnement au portefeuille d’identité principal. Il est aussi possible d’utiliser une extension de navigateur spécialisée (à l’image de “Metamask”). Nous vous tiendrons informés des avancées du développement de cette extension “myDid” pour navigateur.
Cette extension pour navigateur devra donc elle aussi savoir stocker des Attestations Vérifiables venant des émetteurs et les présenter aux vérificateurs en obtenant auparavant le consentement éclairé de l’utilisateur.
Les deux signatures principales sont la signature du Verifiable Credential par son émetteur et la signature du Verifiable Presentation par son détenteur. À noter néanmoins deux autres signatures optionnelles qui peuvent intervenir dans les échanges entre ces trois acteurs :
- Quand le détenteur du portefeuille effectue une demande de Attestation Vérifiable auprès de l’émetteur, cette requête peut elle aussi être signée par l’utilisateur (notamment pour une vérification côté émetteur)
- Quand le vérificateur effectue une demande d’Attestation Vérifiable à l’utilisateur, cette requête peut elle aussi être signée par le vérificateur.
Il semblerait que les requêtes d’Attestations signées soient rarement utilisées dans les requêtes des vérificateurs. La “vérification du vérificateur” par l’utilisateur peut parfois s’effectuer de visu ou partiellement en comparant avec l’identité liée à la communication sécurisé SSL/TLS : le vérificateur n’a pas toujours de DID identifiable (et ce n’est généralement pas une obligation).
Signature des Attestations Vérifiables
Concentrons-nous maintenant sur la partie “Émetteur” d’AV et sur les options possibles pour gérer ses clés et ses signatures.
Dans tous les cas, l’émetteur doit posséder une interface d’administration (plus ou moins automatisable) pour gérer les demandes des utilisateurs. Cette interface doit recevoir et stocker les requêtes des utilisateurs et leurs statuts (après en avoir vérifié la signature) lors de la création des AV.
Nous travaillons sur les trois options possibles pour effectuer les signatures :
- L’interface web de l’émetteur utilise le KMS (Key Management System) cloud de son choix, généralement issu des ses propres décisions d’architecture cloud (AWS, Azure, GCP…) ou un KMS privé intégrable compatible KMIP (Key Management Interoperability Protocol).
- Une extension de navigateur comme Metamask qui gère la clé directement au niveau du navigateur (simple protection logicielle) ou qui transmet les demandes de signature à un Hardware Wallet compatible Metamask (exemple : Ledger Nano).
- Un ou plusieurs HSM (Hardware Security Modules) connectés aux serveurs de l’émetteur.
Plusieurs types de signature peuvent être définis à l’intérieur des Attestations Vérifiables mais la signature la plus sensible est celle réalisable via Metamask. En effet, la première méthode de signature possible via Metamask (eth_sign) permettait (et permet encore avec un énorme warning) de signer n’importe quel hash et notamment celui d’une transaction de transfert broadcastable.
Heureusement le support de la signature s’est amélioré avec l’arrivée de l’EIP712¹ (Ethereum Improvement Proposal) et notamment la dernière méthode (signTypedData_v4²) qui est documentée (à l’état de draft pour le moment) comme une solution possible pour les signatures d’AV directement par le w3c³.
Ainsi, en parallèle des solutions pour les utilisateurs d’Attestations Vérifiables que constituent les portefeuilles d’identité (sous forme d’application mobiles, d’extension de navigateur et de carte NFC), nous travaillons aussi sur des solutions “clés en main” d’administration pour les émetteurs d’AV.
Plus d’informations bientôt sur cette grosse partie immergée de l’iceberg.
[1] EIP712 is here: What to expect and how to use it
https://medium.com/metamask/eip712-is-coming-what-to-expect-and-how-to-use-it-bb92fd1a7a26
[2] Official MetamaskDoc : Signing Data
https://docs.metamask.io/guide/signing-data.html#sign-typed-data-v4
[3] w3C Credentials Community Group : Ethereum EIP712 Signature 2021
https://w3c-ccg.github.io/ethereum-eip712-signature-2021-spec/
