The Verifiable Credentials are signed by their issuers before they are sent to the future owner.
The issuer sends the Verifiable Credential to the owner who stores it in his identity wallet, usually a decentralized mobile application (dApp). In a previous article, we indicated that it was possible to have an NFC card as a complementary solution to the main identity wallet. It is also possible to use a specialized browser extension (like Metamask). We will keep you informed about the development of myDid browser extension.
This browser extension will have to store Verifiable Credentials from issuers and present them to verifiers with the user’s prior informed consent.
The two main signatures are the signature of the Verifiable Credential by its issuer and the signature of the Verifiable Presentation by its owner. However, there are two other optional signatures that can be used in the exchanges between these three actors:
— When the wallet owner makes a Verifiable Credential request to the issuer, this request can also be signed by the user (in particular for a verification on the issuer side)
— When the verifier makes a Verifiable Reference request to the user, this request can also be signed by the verifier.
It seems that signed credential requests are rarely used in verifier requests. The verifier verification by the user can sometimes be done visually or partially by comparing with the identity related to the SSL/TLS secure communication: indeed, the verifier does not always have an identifiable DID (it is usually not a requirement).
Signature of Verifiable Credentials
Let’s focus now on the issuer part and the different options available to manage its keys and signatures.
In all cases, the issuer must have an administration interface (more or less automatable) to manage user requests. This interface must receive and store users’ requests and their status (after having verified their signature) when creating VCs.
We are working on three possible options to perform signatures:
— The issuer’s web interface uses the cloud KMS (Key Management System) of its choice, usually derived from its own cloud architecture decisions (AWS, Azure, GCP…) or a KMIP (Key Management Interoperability Protocol) compliant embeddable private KMS.
— A browser extension such as Metamask that manages the key directly in the browser (simple software protection) or that sends signature requests to a Metamask-compatible hardware wallet (e.g. Ledger Nano).
— One or more HSMs (Hardware Security Modules) connected to the issuer’s servers.
Several types of signatures can be defined inside the Verifiable Credentials but the most ‘sensitive’ signature is the one that can be done via Metamask. Indeed, the first possible signature method via Metamask (eth_sign) allowed (but here we put a warning) to sign any hash and in particular that of a broadcastable transaction.
Fortunately, the support of the signature has improved with the arrival of the EIP71²¹ (Ethereum Improvement Proposal) and in particular the latest method (signTypedData_v⁴²) which is documented directly by the W3C³ (at the state of draft for the moment) as a possible solution for VC signatures .
So, along with the identity wallet solutions for Verifiable Credential users (as mobile application, browser extension and NFC card), we are also working on a ‘ready-to-use’ administration solutions for VC issuers.
More information soon on this hidden part of the 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/
