November 23, 2020
Episode 2: This is the second episode of the Sovrin Foundation Interoperability blog post series, highlighting an interoperability achievement between two Sovrin Stewards.
ToIP Stack Interoperability: Technology stack / Layer 2
Back in 1982, Jon Postel introduced a standard internet protocol called Simple Mail Transfer Protocol (SMTP) for sending email from one system to another. The standard was designed to transfer emails reliably and efficiently between two mail servers. This is important, because it allowed us to send a message from one email service (e.g. Gmail) to a different email service (e.g. Outlook) without losing any content or functionality, since both use the SMTP standard. Because the standard proved to be robust, useful and successful, it is still used today when we want to send an email.
Today, in the self-sovereign identity (SSI) space, we face the same issues we did 40 years ago. We need a standardized protocol to securely transmit and store verifiable digital credentials in a peer-to-peer manner. Standards as clear and foundational as SMTP have been slow to emerge because SSI requires an entirely different stack from conventional kinds of data and identity. The Hyperledger Aries project at the Linux Foundation has created such a stack which is collaboratively maintained between many competitors. This stack is now reaching a level of maturity where it can pioneer interoperability with other emerging SSI systems. This promises to be the most widely-adaptable SSI open standard for peer-to-peer messaging, equivalent to SMTP, which has standardized electronic mail to this day.
We, Swisscom Blockchain AG and Spherity GmbH, have adopted the modular Hyperledger Aries approach in the design of our cloud identity wallets, and we are proud to announce that our APIs are interoperable. In a productive pilot we are currently working on in the Swiss pharmaceutical industry using the Sovrin Network, we have offered our wallets to the participants in the consortium. Because our wallets are interoperable, participants can choose between one or the other, and still be able to communicate, issue and verify the same Verifiable Credentials (VC) between our two distinct cloud identity wallets.
We believe this kind of work leads us into the future of SSI because it will allow people and organizations to choose their preferred wallet service provider without running into proprietary formats or vendor lock-in situations. Providing an interoperable solution from the outset would enable all parties to leverage the growth of the ecosystem: the more participants that collaborate together, the more they will be able to exchange data automatically without additional effort.
When we designed the solution, we noticed there are still some aspects we believe are not adequately covered by the current generation of Hyperledger Aries protocols. More precisely, the capability to securely link one or more files to a Verifiable Credential required us to go “off-script” and roll out our own enterprise-grade solution.
One of the business requirements coming from the participants in the pilot was to issue Verifiable Credentials bound to traditional files, i.e. “attachments,” by analogy to email. This requirement generated two sub-requirements that needed to be fulfilled. First, we needed to send attachments separately from the Verifiable Credential (mainly because the size restrictions of a Verifiable Credential don’t allow us to fit large attachments into each attached credential). Secondly, we needed to ensure the attachments linked to a Verifiable Credential were consistent with the original issuance purpose but also tamper-evident.
To fulfil the first sub-requirement, we followed the data attachment specification described in Aries RFC0017. Since the type of attachments was expected to be diverse, including for example a picture or a document, we decided to use base64 encoding to embed the desired content into the DIDcomm message. An example of a data attachment using base64 encoding follows:
Then, in order to ensure the attachment is linked to a Verifiable Credential in a tamper-evident manner, we decided to add an attribute inside each Verifiable Credential which contains the hash of the attachment that is sent in the payload of the DIDcomm messaging, extending the tamperproofing inherent in the VC standard to the attachment. An example of the Verifiable Credential attribute follows:
The proposed solution works for attachment handling only in the case where the number of required attachments is known beforehand by simply including an attribute in the Verifiable Credential that contains the hash of each attachment. But what if the number of attachments is variable and cannot be known beforehand?
The solution we are currently discussing is to include in the DIDcomm message an attachment index file that contains a reference and hash to all the attachments that are sent in the payload of the DIDcomm message. Then, we also hash this index file and include the hash in the Verifiable Credential. This gives us total flexibility in order to use the same Verifiable Credential template regardless of the number of attachments intended to be sent, but also ensuring the attachments are tamper-evident.
We already see some performance limitations in the solutions described above, particularly in the case that the attachments are too big in size. As proposed in the Aries data attachment specification, it is possible to send data by reference through the DIDcomm messaging attachment, i.e., simply sending a link in the DIDComm message that can be fetched separately, whether by software or by human agency. This has the added benefit of making the downloading of heavy content optional for the recipient.
Nevertheless, how do we control the access to and consent tracking of the data? How do we ensure that only the intended recipient of the credential is capable of accessing that data? These issues remain to be decided in a way that works for the entire Aries community.
If you are a Sovrin community member who has successfully implemented a certain Interoperability piece which you would like to share with the community, please contact the Sovrin Communications & Community Engagement Committee at firstname.lastname@example.org to showcase the solution in an Interoperability Series blog episode.« Finhaven Joins Sovrin Foundation as Steward of the Sovrin Network The Principles of SSI »