Solo Study | Mastering Self-Sovereign Identity — An SSI Overview

Personally, I have long been interested in data democracy. While studying Hyperledger Fabric, I came to learn about SCs and DIDs. Around the same time, the Three Data Acts were passed, and what was being shaped in Europe as madata started being introduced in Korea under the name MyData.
As I kept up with this topic on and off, I joined the SSI community, attended seminars they hosted, and gained a broader understanding of the background I had not known before — especially the parts I had only grasped from a technical angle — along with the concerns of today's leaders and the directions the field is heading. Through that community, I also discovered Mastering Self-Sovereign Identity.
As I read it, I want to organize a few impressive passages along with some of my own thoughts.

1. Models

1) Types approached from the technical side 

Looking at digital or internet-based identity simply through the lens of "accounts," it can roughly be summarized into three types.
(1) The centralized identity model is the model where, in order to use a particular service, you sign up, enter your personal information, and create an account (ID and password). Many services adopt this model. 
(2) The federated identity model can be thought of as something like social login. The places that provide the linking APIs are called IDP providers. In practice, these are platform companies like Google, Naver, and Kakao. Personally, rather than calling it a "federation," I see it as more of a crocodile-and-plover relationship. It has been used as a way to ease the burden of managing personal information and security in terms of cost and operations, or to minimize the friction in onboarding new users when a service has not yet built up name recognition. But these days, as the exchange value of personal information in operations and the market has grown, there are many cases where, even after a social login, additional personal information is still being requested — so my personal opinion is that the original purpose has already been considerably watered down.
(3) The decentralized identity model, to put it bluntly, is a model that applies blockchain. But that is just a blunt explanation, and strictly speaking it is not quite right. Conceptually, this is the DID model that has been talked about in many places lately. In reality, blockchain is just a technology that is broadly adopted in some parts of the DID implementation process. And once again, DID is just one of the methods for implementing SSI. So DID is one solution for managing identity in a decentralized way. But just as socialism cannot be equated with democracy, even though it started from the ideal of giving sovereignty to the individual, you cannot say that being implemented as a DID automatically satisfies SSI. 

2) Types based on the managing entity 

Setting the previous breakdown aside, if we divide things by the entity that manages the account and the personal information accumulated through that account, we can group the centralized and federated identity models together on one side and the self-sovereign model on the other. The biggest difference between these two is what one might call a deeply meaningful shift in control. Only the self-sovereign model places the user (the individual) at the center. 

And now, some time after the authors wrote this book, my personal view is that the self-sovereign model can again be split into two: a DID model with full SSI applied, and a DID model with only partial SSI applied. To draw an analogy, the DID model with only partial SSI applied resembles a hybrid electric vehicle in many ways — that comparison would not be too far off. 

2. SSI Composition

1) Basic building blocks

(1) VC — verifiable (digital) credential
(2) Stakeholders that can form the trust triangle (issuer, holder, verifier) 
(3) Digital wallet
(4) Digital agent
(5) DID — decentralized identifiers
(6) Verifiable data — blockchains, etc.
(7) Trustworthy registry governance frameworks

1 — Looking first at VCs, which sound unfamiliar but on closer inspection are actually the most familiar thing in everyday life: as the term itself says, a VC is a credential. That makes it the seed keyword in SSI. Since this post deals with SSI in the online realm, the major premise here is digital credentials. Representative offline examples of credentials would be things like student IDs, resident registration cards, and driver's licenses. Looking at these examples, for the same person — say, Hong Gildong — a student ID is issued by the school as the institution that vouches for his status and affiliation as a student; a resident registration card is issued by the local government with information about his country, region, gender, and so on; and a driver's license is issued by the relevant licensing authority with information about driving type and qualifications obtained. Once the person holds these credentials about himself, he gains the authority to claim and prove the relevant facts to a third party. And beyond credentials about an individual, offline credentials also include things like product warranties, certificates of guarantee, certificates of authenticity, or even the tags attached when you buy clothing — these are all credentials of the same type. Borrowing the polished phrasing from the book, this can be summarized as follows.  

Every credential contains a set of claims about the subject of the credential.
These claims are made by a single authority called the credential issuer in SSI. The party to whom the credential is issued (a person, organization, or thing) — that is, the one who will hold it in their digital wallet — is called the credential holder. The subject of the credential is generally the same as the holder, but as discussed in Chapter 7 there are empirically important exceptions.
The claims in a credential can represent anything about the subject — attributes (age, height, weight, etc.), relationships (mother, father, employer, citizen, etc.), entitlements (medical benefits, library privileges, membership rewards, legal rights, etc.).
For a credential to confer any qualification, claims must be verifiable in some way. That is, a verifier must be able to verify (check, accept) the following:
- Who issued the credential
- That it has not been tampered with after issuance
- That it has not expired or been revoked

2 — The issuer is the party who issues the credential, the holder is the subject themselves who requests, stores, and uses a credential representing their qualifications, and the verifier is the party who needs to verify the holder's trustworthiness and conditions before operating or providing a service. For example, in the case of traveling abroad, the issuer of a passport would be the Ministry of Foreign Affairs, the holder is the individual, and the verifier could be understood as the airport. 

The author describes the process and roles of digital credentials as follows. 

7 — According to the author, 

The ultimate goal of every SSI infrastructure is to achieve a mutually acceptable level of trust between two parties interacting on the internet.
This is a goal that is impossible for many types of transactions today. With SSI, the foundation of this trust layer is first laid by cryptographic trust. That is, publicly resolvable DIDs and public keys are applied for credential issuers on a decentralized network.

As shown in the diagram below, this means an expansion of the trust triangle, allowing externally extended (linked) second and third verifiers and the relaying issuer (who is both an issuer and a holder) to all rely on a single digital signature. Building on this, as the quote above says, it is shifting goals that were impossible in past (and present) transactions into the realm of the achievable. 

That said, the author, citing past examples of banks and credit card networks, emphasizes that cryptographic trust is not human trust. I think this is exactly the backdrop behind Elon Musk's tweet about Web3. Personally, I think what we should be doing right now — or how we should be framing things — is not arguing about whether Web3 exists or not, but rather about timing the search for ways to actually implement it. From that stance, examples like the following strike me as truly precious.

Building human trust on top of cryptographic trust means that SSI can provide trust based on VCs. Trusting a credential issued by a single issuer does not scale all at once. This is the same problem credit cards faced in the early days of the 1960s. Each major bank tried to issue its own brand of credit card, but merchants could not handle hundreds of different credit cards from hundreds of different banks. So credit cards were not really adopted until the banks came together to form credit card networks. Visa and Mastercard are the best-known credit card networks. 

* — A summary of the basic building blocks 

The ToIP layered stack supports an interoperable digital trust ecosystem by combining cryptographic trust at the machine-to-machine layers (1, 2) with human trust at the business, legal, and social layers (3, 4). The term "public utility" is used to refer to the blockchain or verifiable data registry for DIDs. 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=290964757