ARTICLE

The Basic Building Blocks of SSI

From Self-Sovereign Identity by Drummond Reed & Alex Preukschat

This article delves into the constituent parts of Self-Sovereign Identity (SSI), and how they work together.

____________________________________________________________

Take 40% off Self-Sovereign Identity by entering fccreed into the discount code box at checkout at manning.com.

____________________________________________________________

SSI is relatively new, having only emerged onto the Internet stage in 2016. At one level, SSI is a set of principles about how identity and personal data control should work across digital networks. At another level, SSI is a set of technologies which build upon core concepts in identity management, distributed computing, blockchain or Distributed Ledger Technology (DLT), and cryptography.

In many cases these core concepts have been established for decades. What’s new is how they’re put together to create a new model for digital identity management. The purpose of this article is to quickly familiarize you with these seven basic building blocks from a conceptual and technical point-of-view.

1. Verifiable credentials (aka digital credentials)
2. Issuers, holders, and verifiers
3. Digital wallets
4. Digital agents and hubs
5. Decentralized identifiers (DIDs)
6. Blockchains
7. Governance frameworks (aka trust frameworks)

Verifiable credentials

The essence of decentralized identity is “to move the utility and portability of physical identity credentials to our digital devices.” This is why the concept at the heart of SSI is verifiable credentials.

First, what exactly do we mean by the term “credential?” It refers to the pieces of paper, plastic (or, in some cases, metal) that you carry around in your wallet to prove your identity, for example, driving licenses, government IDs, employment cards, and credit cards (figure 1).

Figure 1: Common examples of credentials — not all of which fit in a traditional wallet.

But as this figure illustrates, not all credentials fit in your physical wallet. The term “credentials” extends to any (tamper-resistant) set of information that some authority claims to be true about you, and this enables you to convince others (who trust that authority) of these truths. For example:

• A birth certificate issued by a hospital or vital statistics agency proves when and where you were born and who were your parents.
• A diploma issued by a university proves you have an educational degree.
• A passport issued by a government of a country proves you’re a citizen.
• An official pilot’s license proves you can fly a plane.
• A utility bill proves you’re a registered customer of the utility that issued the bill.
• A power of attorney issued by the appropriate authority within a jurisdiction proves that you can legally perform certain actions on behalf of another person.

In one form or another, every credential contains a set of claims about the subject of the credential. Those claims are made by a single authority, which in SSI is called the issuer of the credential. The entity (person, organization, or thing) to whom the credential is issued, i.e, the one who keep it in their digital wallet, is called the holder of the credential. Note that the subject of the credential is often the same as the holder, but there are important exceptions to this rule-of-thumb.

The claims in a credential can state anything about the subject, such as attributes (age, height, weight, etc.), relationships (mother, father, employer, citizenship, or others), or entitlements (medical benefits, library privileges, membership rewards, or legal rights).

To qualify as a credential, the claims must be verifiable in some way. This means a verifier must be able to determine the following:

• Who issued the credential
• That it hasn’t been tampered with from the time it was issued
• That it hasn’t expired or been revoked

With physical credentials, this is typically accomplished through some proof of authenticity embedded directly in the credential itself (like a watermark, hologram, or some other special printing feature). You can also check directly with the issuer to verify that the credential is valid, accurate, and current. But this manual verification process can be difficult and time-consuming — a major reason why there’s a worldwide black market in falsified credentials.

This brings us to one of the fundamental advantages of verifiable credentials: using cryptography and the Internet, they can be digitally verified in seconds. This verification process can answer the following four questions:

1. Is the credential in a standard format which can be electronically processed by the verifier and does it contain the data the verifier needs?
2. Does it include a valid digital signature from the issuer (establishing its origin and that it hasn’t been tampered with in transit)?
3. Is the credential still valid, neither expired or revoked?
4. If applicable, does the credential (or its signature) provide cryptographic proof that the holder of the credential is the subject of the credential.[1]

Figure 2 is an illustration from Manu Sporny, co-editor of the Verifiable Credentials Data Model 1.0 specification, showing how a digital credential can be structured to answer these four questions. The first part of the verifiable credential package is a unique identifier for the credential — just like the unique number shown in the figure that appears on your driving license or passport. The second part is metadata describing the credential itself. In this example, this is the expiration date for the driving license credential. The third part is the claims contained in the credential — in the image, these are all the other items of data (name, date of birth, sex, hair color, eye color, height, weight).

Figure 2: A mapping of three of the four core components of a W3C verifiable credential to the physical equivalent. The fourth component — the issuer’s digital signature — can only be produced in a physical credential by some form of watermark, hologram, or other hard-to-forge seal.

The equivalent of the credential subject’s signature (the one that appears below the person’s picture in the driving license) is a digital signature created using cryptography.

Issuers, holders, and verifiers

Figure 3 illustrates the terminology defined by the W3C Verifiable Claims Working Group[2] for the three primary roles involved with the exchange of verifiable credentials.[3]

1. Issuers are the source of credentials — every credential has an issuer. Most issuers are organizations such as government agencies (passports), financial institutions (credit cards), universities (degrees), corporations (employment credentials), NGOs (membership cards), or churches (awards). Individuals can also be issuers, as can things — for example a properly equipped sensor could issue a digitally-signed credential about a sensor reading.
2. Holders/Provers request verifiable credentials from issuers, hold them in the holder’s digital wallet (below), and present proofs of claims from one or more credentials when requested by verifiers (and approved by the holder). Although we most commonly think of individuals as holder/provers, holders/provers can also be organizations using enterprise wallets, or things in the sense of the Internet of Things (IoT).
3. Verifiers can be anyone — person, organization, or thing — seeking trust assurance of some kind about the subjects of credentials. Verifiers request proofs from holders/provers of one or more claims from one or more verifiable credentials. If the holder agrees (and the holder always has that choice), the holder’s agent responds with a proof the verifier can verify. The critical step in this process is verification of the issuer’s digital signature, typically accomplished using a DID, discussed in more detail later in this article.

Figure 3: The primary roles involved with exchange of verifiable credentials. Digital signature verification is the part of the process enabled by public or private blockchain networks.

The relationship between issuers, holders/provers, and verifiers is often referred to as the trust triangle because it’s fundamentally how human trust relationships are conveyed over a digital network. Figure 4 illustrates how verifiable credentials only convey trust if the verifier trusts the issuer. This doesn’t mean the verifier needs to have a direct business or legal relationship with the issuer. It means that the verifier is willing to make a business decision (“Will I accept this credit card?”, “Will I board this airline passenger?”, “Will I admit this student?”) based on the trust assurance the verifier has in the issuer.

Figure 4: The “trust triangle” at the heart of all human trust relationships in the SSI ecosystem.

Note that the trust triangle describes only one side of a business transaction. In many business transactions, both parties request information from the other. In a single transaction, both parties play the roles of holder and verifier. Also, many business transactions may result in a new credential issued from one party to the other — or even two new credentials, one in each direction.

An example of this is shown in figure 5, which describes the series of steps a consumer goes through buying an expensive holiday trip from a travel company:

• The consumer wants to verify that the travel company has insurance against bankruptcy.
• The travel site wants to verify that the consumer is older than 18.
• After payment, the travel site sends the tickets to the consumer.
• After the trip, the consumer confirms that he is a satisfied customer of the travel company.

Each of these pieces of information can be transmitted as a verifiable credential with a digital signature from the issuing party. It shows how both parties intermittently perform all roles in the trust triangle.

Figure 5: A typical multi-stage transaction where multiple verifiable credentials are used and created and both parties play the role of issuer, holder, and verifier.

Digital wallets

In the offline world, we typically store credentials in a physical wallet — it keeps them all in one place, protects them by keeping them close to our body, and makes them easy to carry around and access when we need them. The job of a digital wallet is no different:

1. Store your credentials, keys/keycards, bills/receipts, etc.
2. Protect them from theft or prying eyes.
3. Keep them handy — easily available and portable across all your devices.

Unfortunately, there have been enough attempts at digital wallets over the years that many developers stopped using the term, but two trends have brought the concept back into vogue. The first is mobile wallets, particularly those built-in to the operating system of smartphones to hold credit cards, tickets, boarding passes, and other typical financial or travel credentials.

Figure 6: Two of the most popular smartphone mobile wallets — Apple Wallet and Google Pay. They are widely used because they come built-in to every Apple and Google phone.

The second is cryptocurrency wallets. Every purchaser of a cryptocurrency like bitcoin, ether, litecoin, and others needs either a server-side wallet, in which keys are stored by a broker such as Coinbase, or a client-side wallet (edge wallet) which is either a dedicated hardware wallet or an app that runs on one or more of the user’s devices (smartphone, tablet, laptop, etc.).

Figure 7: A typical dedicated hardware wallet for cryptocurrencies. This one is called Ledger Nano S and has its own secure display.

For SSI, any of these general forms of a wallet work, but there are also some key differences, including the following:

1. An SSI digital wallet should implement open standards for portable, self-sovereign verifiable credentials and other sensitive private data.
2. An SSI wallet works with a digital agent to form connections and perform credential exchange (discussed in the next section).

For SSI to fulfill its full potential instead of proprietary wallets from different vendors, where each wallet uses that vendor’s own APIs and verifiable credential designs, we need general-purpose digital wallets that function much more like the real-world wallets we carry in our pockets or purses.

• The wallet should accept any standardized verifiable credential (or other standardized information artefact) like you can fit any paper or plastic credential of the right size into your physical wallet.
• You can install the wallet on any device you regularly use, like you can put a physical wallet in the pocket of any clothes you wear or purse you carry. Unlike physical wallets, your digital wallets should automatically stay “in sync” across your different devices the same way your email and messaging apps do today.
• You can back up and move your keys and verifiable credentials between digital wallets as needed — even from different vendors — like you could move your physical credentials from one wallet to another.
• You should have the same basic experience no matter what wallet[4] you use — even across different wallets from different vendors — because this is critical to being able to use your wallets safely and securely.

Adam Gunther, former Executive Director for Blockchain Trusted Identity at IBM and now VP Identity at Equifax, expresses this last point as, “one wallet, one experience”[5] — one standard way of managing your verifiable credentials and trust relationships no matter what wallet or device you’re using. Not only is it the easiest experience for end-users, but it’s also the safest approach, because it makes it much harder to fool or “phish” an identity owner into doing the wrong thing.

Kim Cameron, Microsoft’s Chief Identity Architect, felt this was important and he made it the last of his seven Laws of Identity.[6] He called it “Consistent Experience Across Contexts.” He compares it to what we need to learn to know how to drive. The worldwide automotive industry has standardized the controls for driving (e.g., steering wheel, accelerator, brakes, turn signals) across all makes and models of cars to minimize the learning experience and maximize safety for drivers. The reasons are obvious: a car which doesn’t operate the way a driver normally expects could kill the driver or others. We need the same level of attention to the safety of our digital lives.

Digital agents and hubs

The second major difference between a digital wallet and a physical wallet is how it operates. A physical wallet is “operated” directly by a person — the owner. He or she sets it up, adds credentials as they are created or acquired, selects credentials to be presented to a verifier when a proof is required, and moves the wallet from pocket-to-pocket or purse-to-purse when the owner needs the wallet in different places.

Because people don’t “speak” in digital bits and bytes, digital wallets require software to operate them. In SSI infrastructure, this software module is called a digital agent, or agent. As figure 8 illustrates, you can think of an agent as a digital guardian which “wraps” around your digital wallet to protect it and makes sure that only you, the person responsible for your verifiable credentials and cryptographic keys, can take them in and out to use them.

Figure 8: In SSI infrastructure, every digital wallet is “wrapped” by a digital agent that acts as a software guardian, making sure that only the wallet’s controller (typically the identity owner) can access the stored verifiable credentials and cryptographic keys.

In SSI infrastructure, an agent has a second job in addition to helping identity owners manage their wallets. Using instructions from their owners, agents “speak” to each other over the Internet to form connections and exchange credentials. They do this via a decentralized secure messaging protocol which is designed from the ground up for private communication between digital agents.

Figure 9 is a high-level overview of how agents and their wallets form connections and communicate in the SSI ecosystem.[7] Two general categories of agents are based on where they are located: edge agents operate at the edge of the network, on identity owner’s local devices, and cloud agents operate in the cloud, where they’re hosted either by standard cloud computing platform providers or specialized cloud service providers called agencies.

Figure 9: An overview diagram of the role of agents and wallets in the SSI ecosystem. Identity owners interact both directly with edge agents operating on local devices and indirectly with cloud agents operating remotely in the cloud.

Cloud agents can also be designed to store and synchronize other data on behalf of an identity owner, e.g., files, photos, financial records, medical records, asset records, etc. These encrypted data stores are called identity hubs, digital hubs, or hubs.[8] They can serve as the backbone for digital life management applications and services that process and maintain digital identity data of all kinds for the lifetime of an individual — and beyond, i.e., a digital hub can be of great assistance in the management and settlement of a digital estate after its owner has passed away.[9]

The next question is how do agents find each other to connect and communicate on behalf of their identity owners?

Decentralized Identifiers (DIDs)

What made the Internet possible was a new addressing system which allows any device on the Internet to form a connection with and send data packets to any other device on the Internet. Figure 10 is a diagram of an IP (Internet Protocol) version 4 address.

Figure 10: Example of an IP address — the addressing format that let any device on the Internet talk to any other device on the Internet.[10]

Knowing the IP address of a machine on the Internet doesn’t tell you anything about the identity of the person, organization, or thing controlling that machine. To do that, the controller (the identity owner) needs to be able to provide proof about their identity, attributes, relationships, or entitlements. And that proof has to be verifiable in some way.

For many years we’ve had a technology for creating digital proofs: public/private key cryptography.[11] The owner of a private key uses it to sign messages, and anyone else can verify this signature using the owner’s corresponding public key. The signature verification shows that the signature was created by the owner of the private key and that the message hasn’t been tampered with.

To rely on this verification the verifier must know the correct public key for the owner. For decentralized messaging between digital agents and wallets to be secure — and for agents to be able to send cryptographically-verifiable proofs of verifiable credentials to each other — we need a strong, secure, scalable way for identity owners and their agents to prove ownership of their public keys.

Like with the Internet, the answer was a new identification system. Only this time the identification system needed to be designed from the ground up for digital agents and their public keys. And because it needs to be extremely secure, this new type of identifier needed the following four core properties:

1. Permanent. The identifier needs to be able to never change, no matter how often the identity owner moves, uses different service providers, or uses different devices.
2. Resolvable. The identifier needs to be able to retrieve not only the current public key or keys for the identity owner, but also the current addresses to reach the owner’s agent or agents.
3. Cryptographically verifiable. The identity owner needs to be able to prove, using cryptography, that he, she, or it has control of the private key for each public key associated with that identifier.
4. Decentralized. Unlike X.509 certificate trees which rely on centralized registries under the control of single authorities, this new type of identifier must be able to avoid single points of failure by using decentralized networks such as blockchains, distributed ledgers, distributed hash tables, distributed file systems, peer-to-peer networks, etc.

It’s the last of these four properties that gave this new address its name: DID (decentralized identifier). Given its different purpose, a DID has a much different structure than an IP address. An example DID is shown in figure 11.

Figure 11: An example of a DID (Decentralized Identifier) on the Sovrin DID network. A DID functions as the identifier of a public key on a blockchain or another decentralized network. In most cases it’s also the identifier for locating an agent for the entity identified by the DID.

As the original research for the Internet was sponsored by a U.S. government agency (DARPA), the original research and development for the first DID specification was also done under a contract with the U.S. Department of Homeland Security (DHS). Published in late 2016, it was subsequently contributed to the W3C Credentials Community Group (CCG) to start the process of becoming an official standard.[12] That process resulted in the launch of the W3C DID Working Group in September 2019.[13]

DIDs are designed to take advantage of any modern blockchain, DLT, or other decentralized network via a DID method which is written specifically for that target system. The DID method defines the following four atomic operations on any DID:

1. How to create (write) the DID and its accompanying DID document (the file containing the public key(s) and other metadata describing the DID subject) to the target system.
2. How to use the DID to read (look up) the DID document from the target system.
3. How to update the DID document for a DID, e.g., to rotate a public key.
4. How do deactivate a DID by terminating its usage (usually by updating its DID document to contain no information).

The DID in the previous figure uses the Sovrin DID method (did:sov:) written for the Sovrin SSI network.[14] The informal DID Method Registry[15] maintained by the W3C CCG includes the DID methods for more than thirty different target decentralized networks, including (at the time of publication) three methods for Bitcoin and five for Ethereum. It also includes two methods (did:peer: and did:git:) that don’t need a distributed ledger because they work entirely peer-to-peer.[16]

As any two devices with their own IP addresses can use the TCP/IP protocol stack to form a connection and exchange data, any two identity owners with DIDs can also use the SSI protocol stack to form a cryptographically secure connection to exchange data. The basic concept of DID-to-DID connections (shown in figures 8 and 9) isn’t new — it’s directly analogous to how connections work in many other networks. But DID-to-DID connections bring five powerful new properties to digital relationships:

1. Permanent — the connection will never break unless one or both parties want it to.
2. Private — all communications over the connection can be automatically encrypted and digitally signed.
3. End-to-end — the secure connection has no intermediaries.
4. Trusted — the connection supports verifiable credential exchange to establish trust to any level of assurance.
5. Extensible — the connection can be used for any other application that needs secure, private, reliable digital communications.

Blockchains

A DID can be registered with any type of decentralized network — or even exchanged peer-to-peer. Why would someone choose to register a DID on a blockchain? What do blockchains provide that other types of electronic identifiers and addresses we’ve used for decades — telephone numbers, domain names, email addresses — don’t?

The answer is deeply rooted in cryptography, databases, and networking. Blockchains are highly tamper-resistant transactional distributed databases that no single party controls. This means they can provide an authoritative source of data which many different peers can trust without any single peer being in control. Blockchains intentionally trade off many other standard features of distributed transactional databases — performance, efficiency, scalability, searchability, ease of administration — to solve one difficult problem — trusted data that doesn’t need to rely on a central trusted authority.

Figure 12 illustrates the fundamental design differences in design between traditional databases — whether centralized or distributed — and blockchains.

Figure 12: The fundamental innovation of a blockchain as a transactional database is that it has no centralized administrator or controller — it uses cryptography to allow many different peers to each control their own transactions, while making it nearly impossible for anyone to alter any transaction once it has been written to the blockchain.

It’s important to understand how blockchains accomplish the feat of removing the need for a central authority and maintain high trust in the integrity of the data. It’s not only cryptography, it’s a triple play of cryptography:

1. Every transaction (the writing of a new record) to a blockchain is digitally signed. This is how control of the distributed database is spread out across all the peers — every peer manages its own private keys and digitally signs its own transactions with the blockchain, and no new transaction is accepted unless the signature is verified.
2. Transactions are grouped into “blocks” which are cryptographically hashed and linked to the previous block. This is the step that creates an immutable “chain” of ordered transactions.
3. Every new “block” is cryptographically replicated across all peer nodes on the blockchain network, each of which is run by a different party. This is the step performed by the consensus protocol at the heart of many blockchains. Many different consensus protocols exist — some of which (like Bitcoin) involve cryptographic proof-of-work called “mining”. But regardless of the specific protocol, in the end every peer node in the network ends up with a copy of the latest “block”, and they all agree on that copy. The fact that each node is run by a different party combined in some cases with clever game-theory makes it far less likely that fifty-one percent or more of the nodes will collude in order to try to attack the blockchain (and have some chance of rewriting its history).

This cryptographic triple play is what makes a blockchain hard to attack — modifying even a single bit of a single transaction which has already been recorded to the blockchain and replicated to all the peer nodes requires breaking into tens, hundreds, or thousands of machines and changing them all at once.

From the standpoint of SSI — and specifically for registering and resolving the DIDs and public keys that enable digital wallets and digital agents to securely communicate and exchange verifiable credentials — the differences between the various types of blockchains (permissionless, permissioned, hybrid, etc.) don’t matter much. A DID method can be written to support pretty much any modern blockchain or other decentralized network.

What matters is that blockchains solve a problem that has never had a solution in the history of cryptography: they’re globally distributed databases which serve as a source of truth for public keys without being subject to single points of failure or attack. This is what provides the strong foundation needed for the ubiquitous adoption of the verifiable digital credentials at the heart of SSI.

Governance frameworks

The ultimate goal of all SSI infrastructure is to achieve a mutually acceptable level of trust between any two parties interacting on the Internet — a goal that for many types of transactions isn’t possible today. With SSI, the foundation for this trust layer is first laid by cryptographic trust, i.e., by rooting publicly-resolvable DIDs and public keys for credential issuers in a decentralized network. This anchors the trust triangle shown in figure 4 and again in figure 13, allowing verifiers to rely on the digital signature of an issuer.

But cryptographic trust isn’t always sufficient to achieve human trust. For example, although Bitcoin uses cryptographic trust and game theory to power its system of value exchange, by itself it doesn’t provide any solution to the challenges of Know Your Customer (KYC), Anti-Money Laundering (AML), or Anti-Terrorism Financing (ATF) regulations for money transmission. But cryptographic trust in the Bitcoin blockchain network could be used to anchor a DID for an issuer of verifiable credentials to parties making Bitcoin transactions. Provided that the issuer has enough human trust in their authority (for example, a credit union, bank, insurance company, or government agency), those verifiable credentials may be used by verifiers to satisfy KYC or AML regulations.

This layering of human trust on top of cryptographic trust is how SSI delivers the full power of verifiable credentials. But trusting in credentials from one issuer at a time doesn’t scale. This was the same problem faced in the early days of credit cards in the 1960s. Each major bank tried to issue its own brand of credit card, and merchants were overwhelmed — they couldn’t handle dozens of different credit cards from different banks.

Credit card adoption didn’t take off until banks got together and formed credit card networks — Visa and MasterCard being the two best known. Each of these is governed by a set of business, legal, and technical rules known as a governance framework (also known in the digital identity industry as a trust framework). The entity that creates and administers a governance framework is known as the governance authority.

A governance framework creates the second trust triangle shown in the lower half of figure 12. This illustrates how a governance framework can make a verifier’s job easier: when presented with proof of a credential from an issuer the verifier doesn’t know, the verifier can request a second proof from the issuer (now acting as a holder/prover) proving a user is authorized under a governance framework the verifier trusts. This proof comes from another verifiable credential issued by the governance authority to the issuer. This approach of “recursive trust triangles” can work for any size trust community — even Internet-scale trust communities where verifiers don’t directly know all the issuers (e.g., MasterCard and Visa).

Figure 13: Governance authorities and governance frameworks represent a second trust triangle that enables verifiers to determine the authorized issuers for a specific set of verifiable credentials.

Governance frameworks are the “flip side” of a verifiable credential — they specify the policies and procedures that issuers must follow to issue that specific credential. In some cases, they also specify the terms and conditions to which holders must agree to obtain them. And when verifiers are paying issuers for the value of the credential, a governance framework can also specify liability policies, insurance requirements, and other legal and business variables that verifiers can factor into their trust decisions.

Governance frameworks are the secret to how verifiable credentials can scale to work in any size trust community, from a single city to an entire industry, or from one nation state to the Internet as a whole. These verifiable trust communities can be as transformative to our digital lives as credit card networks have been to the world of commerce.

Although an entire book can (and will) be written on each of these seven fundamental building blocks of SSI, the goal of this article was to introduce them to anyone — technical or non-technical — explaining the basic role they play in SSI infrastructure. In fact, we can summarize each building block in a single sentence.

1. Verifiable credentials are the digital equivalent of the physical credentials we carry in our wallets to prove some aspect of our identities almost every day.
2. Issuers, holders, and verifiers are the three roles of the “trust triangle” which make credentials of any kind work: issuing the credential, holding it in a wallet, and verifying it when it’s presented by the holder.
3. Digital wallets are the digital equivalent of our physical wallets for holding verifiable credentials on any modern computing device — smartphone, table, or laptop.
4. Digital agents are the apps or software modules which enable us to use our digital wallets to obtain and present credentials, manage connections, and securely communicate and exchange verifiable credentials with other digital agents.
5. Decentralized identifiers (DIDs) are a new type of digital address which is both generated and verified using modern cryptography that allow DIDs to not require any kind of centralized registration authority.
6. Blockchains are globally distributed, cryptography-protected databases which can serve as a source of truth for DIDs and public keys without being subject to single points of failure or attack.
7. Governance frameworks are the set of business, legal, and technical rules for how SSI infrastructure is used which are published by a particular governance authority which is trusted by the members of a particular trust community.

That’s all for this article. You can see more of the book’s contents on our browser-based liveBook platform here.

[1] This feature can be supported by zero-knowledge proof (ZKP) cryptography.

[2] The Working Group has the name “W3C Verifiable Claims Working Group” even though the specification it’s creating’s called “Verifiable Credentials Data Model 1.0”. For more details on the terminology and standards for verifiable credentials, see the Verifiable Credentials Primer (https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/verifiable-credentials-primer.md) by Manu Sporny and the W3C Verifiable Credentials Data Model 1.0 (https://www.w3.org/TR/verifiable-claims-data-model/).

[3] From Appendix G of the Sovrin Glossary V2.

[4] For more about interoperability and standardization across SSI digital wallets, please see the chapter on digital wallets in Part 2. That chapter also answers the other most frequently-asked question about digital wallets: what happens if I lose my phone? (Without spoiling the punch line, the answer is: by automatically maintaining an encrypted backup, your digital wallet’s much safer and more secure from loss, theft, or hacking than any physical wallet you can carry.)

[5] https://www.ibm.com/blogs/blockchain/2019/04/episode-1-the-future-of-protecting-your-wallet-and-identity/

[6] http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf

[7] From Appendix F of the Sovrin Glossary V2.

[8] The Decentralized Identity Foundation and Hyperledger published a joint paper on how agents and hubs work together: https://medium.com/decentralized-identity/rhythm-and-melody-how-hubs-and-agents-rock-together-ac2dd6bf8cf4

[9] Agents, hubs, decentralized secure messaging, and other aspects of decentralized identity architecture are covered in more detail in the technology architecture chapter.

[10] From https://en.wikipedia.org/w/index.php?title=IP_address&oldid=888840206

[11] We explain the basics of public/private key cryptography in our cryptography chapter.

[12] See the DID chapter for more about DIDs, DID documents, DID methods, and the DID specification.

[13] https://www.w3.org/2019/did-wg/

[14] https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html

[15] https://w3c-ccg.github.io/did-method-registry/

[16] https://dhh1128.github.io/peer-did-method-spec/index.html

This article was originally published here: https://freecontent.manning.com/the-basic-building-blocks-of-ssi/