In the Netherlands, there are many authorization registers which enable people to share information at the right time, with the right people. Visma manages several of these authorization registers. Among other things, these registries contain information about the mandating person and authorized representative, as well as their rights and duties.
For instance, a mandating person might authorize a tax advisor to submit their tax declarations. Current registers store the identifiers of both the mandating person and the authorized representative. These digital identities are mostly third-party controlled. For example, a Google ID is controlled by Google, and DigiD is controlled by the government. A self-sovereign identity (SSI) is a new type of identity where identifiers are not controlled by third parties. At Visma Connect, we are looking into SSI as a means to enhance privacy protections and reduce the amount of information we need to store, therefore reducing our costs. Using SSI for authorizations could potentially eradicate the need to store identifiers in our systems entirely. SSI also greatly reduces the risk of leaking personal information. Let’s explore how.
What is SSI?
SSI is an identity that follows ten principles outlined in Christopher Allen’s article, “The Path to Self-Sovereign Identity.” In short, it’s an identity that puts the user in control, and discloses as little information as possible when presenting claims about their identity. Control in this sense doesn’t mean a user can just make random claims about him or herself. It means that they control their own identifiers. Normally, people identify themselves using a bank account, email address or phone number - all of which are owned by third parties such as banks and corporations like Google or KPN. These platforms can censor their users and take over their identifiers. With SSI, the user manages their own identifier. The identifier is stored in smartcards or devices, such as phones or tablets.
To this end, most SSI solutions use so-called decentralized identifiers (DIDs). A DID is essentially a unique string of characters that unambiguously identify a particular resource. DIDs are unique for every party. For example, my DID with Rabobank is different from my DID with ING. This prevents people from correlating my behaviour or, in other words, applying data science to uncover more information about me based on my internet activity.
Putting DIDs in the hands of the user addresses the matter of control. What about disclosing as little required information as possible? This is best explained with an example. Currently, when you go to the supermarket to buy liquor you might be asked to show your ID to verify that you are over 18 years old. Your ID contains much more information than just your age. It lists your gender, social security number, and more. With SSI, the idea is to show just the fact that you're over 18 years old. So not even your age is required. Let alone, all the extra data you risk exposing. To reach this goal, most SSI solutions are credential-based. Meaning, instead of showing an ID, the holder can show credentials that say 18+, 21+, or 65+ instead of the actual age. These credentials can all be requested independently. The supermarket wouldn’t need to see your entire identity, just the required 18+ credential.
You might be asking how one knows these credentials are valid. We know that with many identities, such as Google and Facebook, you can just create fake accounts. To address this, SSI uses several roles: an issuer, a holder and a verifier. These are visualised in the diagram below (source: Trust Over IP Foundation).
A holder in this scenario, is a user that wants to use SSI to authenticate him or herself. The issuer is someone, or an organization, that issues claims to the holder. A verifier is someone, or a party, that requires proof from a holder about their identity. While a holder can also issue their own credentials, these typically can’t be used in many scenarios, like buying liquor in the supermarket. In this case, the supermarket (being a verifier) wants proof of what’s deemed a “verified credential” in SSI. To have a verified credential, we require trusted parties like banks or the government to issue a validated credential about our age to our SSI wallet. Unlike a self-issued credential, a verified credential is signed by a known trusted party, so the verifier can validate that this credential can be trusted.
In the above diagram, a blockchain is used to verify who signed the credential. Technically, this can be done without a blockchain. There are SSI solutions like IRMA that work well without using a blockchain. The advantage of using a blockchain is that the issuer can use its public key to revoke the issued credential by updating a revocation hash on the blockchain.
Authorizations using SSI
As we mentioned in the introduction, authorization registers contain identifiers about the mandating person and the authorized representative. A verifier can check authorization registers to look up who is authorized by whom. Our goal is to create an SSI attribute which can be issued on our platform by the mandating person, or delegator, to the authorized representative. For this attribute to work, both parties need to sign the attribute and include their identifier in the attribute:
his attribute must require some information about what the authorization entails. So, it contains at least the following information:
- An identifier of the authorized representative.
- An identifier of the delegator.
- A proof section that includes among other things, a signature of the delegator which their approval for the authorized representative to act on his/her behalf.
- The boundaries of the authorization (to what extent is the authorized representative authorized).
The authorized representative can present this attribute to a verifier to prove he/she is authorized by the mandating person and is authorized to act on their behalf.
The advantage of this approach is that no personal data is stored in our authorization module. Our module only creates attributes based on standardized schemas, and credential definitions are published on the blockchain. Verifiers can check that the authorization attribute was issued by us by verifying that it was signed using our public DID. This way, the verifier can trust the used schema. We have also built in a revocation mechanism, such that the delegator can revoke the authorization when necessary.
Want to learn more about SSI and our approach? Stay tuned to hear more about our presentation at the online hackathon, Odyssey Momentum.
