Our latest release Bellatrix introduces enhanced login security, a new payment system, and multi- and subtenant architecture for large enterprises.

Many people are talking about Web 3.0, Self Sovereign identity, blockchain, decentralized data and data meshes are definitely some trendy buzzwords these days, But, buzzwords that are shifting the technological landscape and giving YOUR customers or users new dynamics with their data creating a true omni-channel experience. Yup, another buzzword, but legit and something organizations have been trying to achieve for generations.  Sit back, relax, and read further to find out how you can be part of the movement and fix a disjointed process that is very costly to your organization and your humans (customers and employees).

The word identity describes “who a person is or more specifically what kind of qualities a person or group possesses that distinguishes them from others.” A digital identity, however, is the body of information about an individual, organization, or electronic device which is adopted or claimed in cyberspace. It arises organically through the online actions of each individual and is formed through many different characteristics and attributes. But unlike with a physical ID, it is possible for one single user to have many different digital identities all over the web, and users are also able to give selective information when providing authentication information. Some examples of identifying data points that form digital IDs include: Date of Birth Medical history Online activity, e.g. search history or electronic transactions Password Purchasing behavior/history Social Security Number Username These unique identifiers and use patterns make it possible to detect individuals and their devices. At the same time, users are able to share their data with multiple service providers. Website owners, advertisers, and many other companies often use this information to identify and track users and their online behavior. This allows them to customize their offers and create targeted ads with specific content tailored to the user’s interests. When talking about digital IDs, it is also important to mention concerns in regards to security and privacy, especially in the area of digital identity management. Digital authentication and validation are critical to hinder identity theft and ensure web and network infrastructure security, both in the public and private sectors. What makes a digital ID trustworthy? Although digital IDs open up a lot of possibilities, they are also very complex and hard to navigate. How can you be sure that the information provided through this digital ID is authentic? First of all, every ID should be verified and authenticated to a high degree of security. These so-called high-assurance IDs have multiple use cases in both the civic and economic sectors such as gaining access to education, opening a bank account, and establishing credentials for a job. The reason and necessity for their easy implementation and acceptance are that they meet government as well as private-sector institutions’ standards for initial registration. The second characteristic that a “valid digital ID” should fulfill is uniqueness. This means that an individual has only one identity within a system, and every system identity corresponds to only one individual. As you probably already know this isn’t the case for most social media identities, so multiple identities are often used to hide or to act fraudulently. Furthermore, digital identities should be established with individual consent, meaning that users knowingly register for and use a digital ID. This also includes total knowledge of what personal data will be accessed and how it will be used. And last but not least, a digital ID should protect the privacy of the user and give him/her control over their own personal data. This could be achieved through decision rights concerning who can access the data and built-in safeguards to ensure privacy and security for the user. If these requirements are met and the information that is provided through the digital ID is verified and authenticated, a so-called “trusted digital ID” is formed. This special form of a digital ID provides a certifiable link between an individual and their digital identity because it consists of a set of verified attributes. Some examples of such attributes are verification with third parties such as Government databases, social identity, credit card numbers, or mobile records. Benefits of digital IDs When it comes to Public Administration, the most prominent benefit of implementing digital IDs is the increase of digitalization as well as security. A trusted digital identity could lead to users accessing multiple security-sensitive services such as mobile money, eGov, and online banking, allowing mobile network operators (or MNOs) to take a lead in these fast-growing sectors. In the private sector, certain enterprises like MNOs, OEMs (or Original Equipment Manufacturers), and others could benefit from improved efficiency and reduced expenses on identity and access management, faster customer acquisition processes, and consistent customer data improved security as well as enhanced user privacy. The end users would also benefit from a secured and authenticated digital ID in the form of more security, enhanced trust, improved UX as well as accessibility to public administration. Use Cases Now, this all sounds very convincing and useful but are there any real-life examples? In many countries, digital identities are already being used in many different ways. In Estonia for example, digital IDs are used to access all citizen’s accounts. This includes eHealth, eVoting, eBanking, eSchooling, eSignature etc. In Indonesia they are trying to synchronize all IDs (personal, tax, etc.) into a single digital ID and India already has a UPI system for mobile-to-mobile payment system in place. 1.4 Mio. people have already registered for a digital cash transfer program launched in 2020 (Novissi program) in Togo. Australia has already implemented a digital ID system, while  Germany has signed joint declarations with Netherlands, Spain, and Finland to form digital identity working groups that coordinate measures to implement the set out objectives. The availability of technologies that make these initiatives possible is expanding exponentially over the years. Among these, technologies like Self-Sovereign Identity (or SSI) could reshape the way personal data is stored by providing a faster, more efficient, and user-centric decentralized approach as by using this technology, data would be stored on the customer side, instead of on the merchant side, eliminating many threats stemming from centralized storage. To give you a better understanding, the following programs are SSI developments using digital IDs: IATA Travel Pass, the first verifiable credential capable of providing proof of COVID-19 test and vaccination GLEIF(Global Legal Entity Identifier Foundation), committed to following the SSI model for digital ID credentials for companies MemberPass, bringing SSI to financial services with Credit Union customer ID verification SSI4DE, co-funded by the German Federal Ministry of Economic Affairs, supports showcases for secure digital IDs NHS Staff Passport, the first portable digital ID credential for doctors and nurses Lumedic Exchange, the first network designed exclusively for the patient-centric exchange of healthcare data Farmer Connect, enabling and empowering individual coffee farmers to more easily work with global enterprises. Summary All in all, there are numerous benefits of digital IDs and the technology to implement them already exists, especially when it comes to SSI which offers numerous possibilities. In addition, they could offer huge social advantages such as reducing fraud risks, increasing privacy and security, and making public services more accessible. So as long as they fulfill all the requirements for trusted digital identities there is no reason to ignore this technological development. Sideos’ mission is to give people the opportunity to own their data and achieve more around the world by providing a safe, reliable, and simple data ecosystem backed up by SSI. Our decentralized data management system allows businesses and organizations to create verifiable credential templates for their end users that are now able to control what information they wish to receive, share, and verify. This brings countless advantages to both the businesses, who no longer need to store users’ personal information with all the consequent risks, and to the people who will finally have ownership of their digital identities and an improved digital experience.

In this paper, our goal is to address an issue related to the exchange process of verifiable credentials, and suggest a first standard solution to be used by the Self Sovereign Identity community. Verifiable Credentials and Verifiable Presentations are described as standard objects in the W3C web pages (https://www.w3.org/TR/vc-data-model/ ). If implemented as defined there, different providers can be interoperable with each other because the data structure during the exchange can be verified against the standard definition. However, one of the issues we have discovered through our work at sideos is how to exchange the data among the actors in a digital interaction. We have tested several issuers of Verifiable Credentials and each of them used a different mechanism to provide such information to the holder. In many cases, the answer to how they exchange such information is not documented. As a consequence, these Verifiable Credentials are either very difficult to use, or can only be used with their provided app. We will try to use the standard definitions of the W3C Verifiable Credentials and Verifiable Presentations to achieve and document a standard process to exchange data during an interaction. This will make the exchange of Verifiable Credentials interoperable if the process described in the following paragraphs is used. Definitions As described in the W3C pages, a Verifiable Credential is essentially a JSON object, which contains a structured data model and can be delivered for use. If multiple Verifiable Credentials need to be delivered, a Verifiable Presentation can be used to include multiple Verifiable Credentials in the same envelope, thus delivering a whole set of them together. The context for which we are describing the following processes is a web interface. We therefore assume that the exchange is done via a web browser and a mobile device. For this discussion, we also assume the use of a JWT to package the Verifiable Presentations and Verifiable Credentials, which can then, for example, be digested by the device via a QRCode. Other ways of packaging the information will work as long as it is standard and well defined. We will use a Verifiable Presentation envelope to propose a standard method to exchange Verifiable Credentials as well as the specific fields “domain” and “challenge”. These fields are part of the “proof” object defined in the standard definition of the model for the Verifiable Presentation. By combining the “domain” and “challenge” fields together, a complete URL can be created. A callback endpoint can be built at that address to receive information from the consumer of the Verifiable Presentation. The Flows During an interaction there are essentially two data exchange flows: Either a Verifiable Credential is offered to a holder by an issuer, or is requested by a verifier from a holder. Let’s call them “Credential Offer” and “Credential Request”, therefore we can create two new types in the Verifiable Presentation “type” field and we can name them “CredentialOffer” and “CredentialRequest”. Credential Request Flow In this flow the verifier packages a Verifiable Presentation and sets the “domain” and “challenge” fields to its backend endpoint callback to verify the data sent by the holder. The application on the holder’s device digests the JWT sent by the verifier, and by using the standard model described in the W3C definitions, parses the JWT and verifies it. Once the JWT is verified, the application can now check what type of interaction needs to be performed, i.e. whether it is a request or an offer. By checking in the “type” field of the Verifiable Presentation the application can identify the request type, in this case we assume it is a “CredentialRequest”. At this point, the application on the holder’s device knows that it has to answer the verifier with the Verifiable Credentials requested in the “verifiableCredential” object within the Verifiable Presentation. Once the application has packaged the answer in a Verifiable Presentation, it is ready to send it back to the verifier using a POST method in the API endpoint identified by the “domain” and “challenge” fields. The application can then post the packaged JWT with the answer to the endpoint. Credential Offer Flow In this flow, the issuer packages a Verifiable Presentation and sets the “domain” and “challenge” fields to its backend endpoint callback to confirm the data, which will be sent back by the holder. The application on the holder’s device digests the JWT sent by the issuer, and by using the standard model described in the W3C definitions, parses the JWT and verifies it. Once the JWT is verified, the application can now check what type of interaction needs to be performed, i.e. whether it is a request, or an offer. By checking in the “type” field of the Verifiable Presentation, the application can identify the request type. In this case we assume it is a a “CredentialOffer”. At this point, the application on the holder’s device knows that it has to answer the issuer with the acceptance of the Verifiable Credentials received in the “verifiableCredential” object within the Verifiable Presentation. Once the application has packaged the answer in a Verifiable Presentation, it is ready to send it back to the issuer who is now able to receive the signed Verifiable Credentials. In order to do that, the application uses a POST method in the API endpoint identified by the “domain” and “challenge” fields. The application can then post the packaged JWT with the answer to the endpoint. Verifiable Presentation Adoption In order to exchange data between entities all parties need to agree on where to send and receive the VCs necessary for the services to work correctly. In most cases, QRCode encoded JWT (Json Web Token) VCs and VPs are the first step to being able to correctly ingest data from a service to a device. If two entities know each other, ingesting a VC via a QRCode is very straightforward as the recipient just parses the content, verifies it, and eventually stores it in his storage area. But what happens when two entities do not know each other? How are they going to exchange information just by reading a QRCode? Some solutions provide a web address on the QRCode data where the recipient should go to retrieve the next piece of information. However, these web services provide a URL where the recipient executes a GET request. This makes it difficult to send any other information attached, as that would require to know what exactly the service can or cannot accept. Therefore, multiple steps are required and this solution is not scalable as there isn't any convergence on how to create these web-based URL endpoints yet. If we use the model of the VP described in the W3C standards, we could achieve a more concise and defined way to exchange information, which will in turn lead to a more interoperable model. In the example above, a better data exchange model with the same results could have been achieved by adding a VP containing the request or offer to the QRCode. The recipient will need to parse the content of the VP, and based on whether the VP contains an “offer” or a “request” will either provide or accept the exchanged data. In the examples that follow below the three flows are explained using the standard W3C VP envelope and the standard W3C VC model. Summary As you can see, the flows are essentially the same and they are interoperable as long as the provider uses the described process to create the JWT packages to be exchanged. We, at sideos, currently use this method which has given us the ability to really ease the infrastructure and the integration effort for our customers. We believe the process described in this paper to be a first proposal to standardize the exchange flows and further facilitate the expansion of Self Sovereign Identity services. Comments, improvements, and constructive criticism are always welcome. 

At the beginning of 2021, we were in the middle of a storm that drastically changed the global economy and the world. Everyone around us rushed into digital services in order to weather this storm. It quickly became clear to us that in a few months the world would not be the same as it was before the pandemic.  The more companies joined the digital ecosystem, the more the structure of the internet changed from central services - hosting all crucial data in a single place - to decentralized services - distributing data to the users. To put it in tech terms: the master-slave architectures slowly became peer-to-peer networks. Blockchain applications and Self-Sovereign Identity standards became more relevant for asset-related interactions in the industry.  We realized that a gigantic opportunity for decentralized identity and data management was rising in the digital market. Therefore, our idea of creating a platform that offers SSI as a Service was born. In March we finished our proof of concept for the service, which was built based on real-world experiences from previous projects. We then connected to the SSI ecosystem by registering our DID method at the W3C and found great partners in Spruce Systems and many more. The team grew quickly and over the summer we found exceptional support in our investors Uneti Ventures as well as in Maikel and Jenny from the Atomico Network. In June we founded the sideos GmbH and started the operational setup. In September we received our first funding.  What happened then was amazing. The majority of the team was completely new to the topic and was asked to square the circle: how can we transform the complexity of SSI and blockchain, including all of the possible difficulties that come with using these technologies in business environments, into a service that fits current business needs while also being easy to understand and use?  It’s safe to say, our team came through. In November not only the APIs were completed but also the backend was running on our own SSI Stack. The connection to the blockchain was running our own smart contracts and the mobile SDKs were ready to be implemented into customers' apps. Only one month later, in December, we had already finished onboarding our first customers. We achieved our first big milestones, which were planned for March 2022, one quarter ahead of time. How did that happen? Lesson learned no. 1: The team’s positive spirit is more important than all the experience and guidance a tech expert can provide. At sideos, the average age is 32, the vast majority of the team is female, we count 8 nationalities in our team of 13 people, and we love to spend time and have lunch together.  Lesson learned no. 2: Sharing learnings immediately and challenging conclusions is crucial for solid results. At the same time it's also important to keep discussions and meetings short, sweet and to the point. Gathering information quickly and implementing it right away keeps the workflow going and avoids spending too much time on one topic. Lesson learned no. 3: Fast decision-making, even if there is a lot of uncertainty, is key to keep moving forward. Discussing a problem within 10 min and making a decision quickly is oftentimes better than keeping things open and unfinished for too long. This keeps the momentum going and fosters real learnings. The next decision is then evidence-based and not another hypothetical working assumption.  That said, we finished the year 2021 with lots of achievements and new learnings. Let’s leverage these insights and rock 2022!

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. Centralized data 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.  Decentralized data 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 signature  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 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 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. sideos Transponder 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.