Exchanging data is the basis of any interactive communication between parties. This data not only needs to be exchanged through a secure channel but also needs to be verified so the parties involved can trust it. This is especially true on the WEB since the data exchange is done in a digital format at distance. This also makes it very difficult to verify the identity of the parties during the interaction.
When exchanging data between parties, current systems store the information in a centralized storage area. At a later point, when such information is needed by a requesting party, the identity of the party is first verified and then the data is pulled out of the storage area and exchanged.
There are two steps involved. The first step is identification followed by data exchange. The data which is being exchanged does not have a property that specifies that it belongs to the party requesting it. In fact, since the identification is done in the first step before the data is even provided, the recipients need to trust the sender in order to offer them the correct information. The connection between the data stored and the person identified exists only because the owner of the centralized data has created it. The data itself does not contain verifiable information of the real ownership.
This means that if the owner of the centralized data loses the internal connection, or if the data is stolen by someone else, the recipients will not be able to access their data anymore, and someone else may use it for other purposes.
In a decentralized system the data is no longer stored in a single place and owned by the service provider but distributed and stored on the owner’s device.
This solves the issue of removing the central storage area but still doesn’t solve the identity problem. In other words, any user can store and use other people’s data on their own device.
A solution to this problem is to add a property indicating ownership of the data stored, making it inherently unusable by others. Only the owner for whom the data was created can use it since the ownership is a property of the data. But how can you verify if the data was provided by the real owner and not manipulated?
Digital signatures use the concept of asymmetric key pairs to sign and verify datasets. We are not going to discuss how private and public keys work in this context; however, it is proven that something signed by a private key can be verified by someone owning a public key.
Therefore, a dataset signed by the owner's private key can be verified by anyone else who has the corresponding public key. In fact, private keys cannot be disclosed; however, public keys must be public in order for everyone to be able to use them to verify the ownership property. If a signature is created and added to the exchanged dataset, the dataset can be verified, and the ownership can be assessed by checking the authenticity of the signature.
Digital signatures have different strengths and use different mathematical algorithms and are very complex to implement correctly and work with. On the other hand, they are very secure and cannot be manipulated easily.
Self-Sovereign Identity, or SSI, is a technology which helps put all the pieces discussed above into a compact and standard solution.
SSI combines data and ownership into one single dataset. It signs the dataset by using digital signatures and then puts the content into an object called Verifiable Credential. A Verifiable Credential, or VC is a document that describes not only a set of data, but also the ownership through the signature. Similar to the digital signatures, a VC can be verified at a later point and therefore trusted.
Given that SSI is a standard defined in the W3C.org, it is meant to be interoperable, i.e. the same VC can be used by different providers as long as they implement the same rules defined in the W3C.org definitions.
How does sideos use SSI?
In the SSI workflows, there are three main actors performing operations.
- The Issuer, i.e. the actor who creates a VC by signing its dataset.
- The Holder, who owns the VC in their storage area.
- The Verifier, who wants to use the data owned by the Holder, verifies its authenticity.
sideos has created a platform which allows organizations to perform all these operations in a simple way. By removing the burden of dealing with the SSI technology complexity, and by offering a simple management console and API, organizations can start using SSI in their services in days, rather than months.
And how does it work? The envelope example
In many situations organizations need to provide some sort of data to their customers, which is then used again at a later point. An example could be a discount code. Company A can issue a discount code to its customers, and eventually they will use it at a later time.
How will this work using SSI?
Imagine that the discount code for Company A is an alphanumeric string, let’s say “BH-9922911”. This can be thought to be the dataset that is being assigned to a customer as a discount credential. It could be a much more complex dataset but for the sake of simplicity, we assume it is a simple string.
This discount code now needs to be signed and given to a customer. It is like putting the discount code into an envelope, then closing the envelope and putting a signature on it.
Now we can deliver the signed envelope to our customer.
At a later point in time, a customer decides to use the discount code they received. The customer provides Company A with the envelope, Company A checks the consistency to make sure nobody has opened it, and eventually, it takes out the discount code which is inside the envelope.
Now Company A can check whether the signature of the customer providing the discount code matches with the one Company A had put in the envelope. If the two are a match, Company A can safely accept the discount code and provide the service. If it does not match, someone has either manipulated the discount code or the person presenting the discount code is not the person Company A meant to issue the code to.
This example shows how we at sideos can provide data to our customers by using SSI and without storing any data on our side. A basic use case using decentralized data concepts. In the process, we not only check the content of the data received but also the identity of the person providing it.
sideos Juno Bridge Platform
At sideos we have built a platform called Juno, which helps solve our customers’ data exchange use cases by using SSI.
We took the envelope example and we renamed the components to make sure it would be easy to understand how to use a complex technology such as SSI.
In our platform we have several components, which match the envelope example objects. The envelope in our Juno platform is called Template, while the discount code dataset is called Proof. Therefore a Template can have multiple Proofs, and can be signed and delivered!
In Juno each customer has a Wallet, which is the place where the signatures take place. So it is easy for our customers to create an envelope, put some data in it and then deliver it.
Of course, the scope of Juno is to manage these assets, so our customers always have everything under control. But the actual signature and dispatch of the VC is done through our Hyperspace or endpoints API.
sideos’ hyperspace provides API endpoints to manage the operations during the data exchange interactions.
There are two types of interactions. One is to issue a VC to someone, i.e. putting data into an envelope, signing it, and delivering it. The other is to request a VC from someone, i.e. asking for a specific envelope that is required to offer certain services.
We have two Hyperspace channels, or API endpoints, to achieve the above mentioned.
One channel is used when a customer wants to issue a VC. The VC will be created using the previously saved Template in the Juno Bridge, filled in with the data needed, and finally signed with the customer’s Wallet keys.
The other channel is used when someone wants to use services, where a customer needs to receive a specifically signed VC. This is the same as asking the user to provide the envelope we had previously sent to them.
We have seen how customers can send and receive envelopes from users through the Juno Bridge and the Hyperspace, but where does a user store and manage these envelopes?
sideos has built a mobile application, our Transponder, which allows users to store and manage their envelopes. Credentials received with an envelope can be stored on the device, and can be provided upon request via a simple interface.
The mobile application also provides the user with a personal Wallet so that credentials can be stored as well as signed in order to confirm their identity when sent to someone. All of this technology is embedded in the Transponder, which can be delivered as an SDK for customers who already have their own mobile application.