Courses / Decentralized Systems / Week 6

Week 6 of 12 · Intermediate

Identity And Keys

You learn how a key pair works as an identity, how decentralized identifiers and verifiable credentials build on it, and how passkeys bring the same idea to everyday logins. You also weigh the real costs of self-sovereign identity.

3 hours18 slides7 min read

Open slides Read study notes

The Identity Problem Public Key Identity Proving Control: Challenge And Response Decentralized Identifiers Verifiable Credentials Passkeys Self-Sovereign Identity And Its Trade-Offs

You Will Be Able To

Explain how a key pair creates an identity without a central registry
Sign and verify a message with a real signature library
Describe the structure of a DID and a verifiable credential and the three roles around them
Explain how passkeys log you in without sharing a secret
Evaluate trade-offs of self-sovereign identity, including key loss and recovery

The Identity Problem

Every service needs to know who is speaking. On the web today the usual answer is an account at a provider: a username, a password and a company that stores them. Your identity lives in that company's database. If the company closes the account, you lose the identity there. If the database leaks, your secret leaks with it.

In weeks 3 and 4 identities already appeared as a worry. A peer that can make unlimited fake identities, the Sybil attack, can overwhelm a network. A voting group that cannot tell its members apart cannot count votes. So decentralized systems need a way for participants to prove who they are without asking a central office.

The tool that makes this possible is the public key pair. It lets anyone create an identity on their own and prove control of it to a stranger.

Public Key Identity

Public key cryptography uses two linked numbers: a private key and a public key. The private key is a secret that only you hold. The public key can be shared with everyone. Whitfield Diffie and Martin Hellman published the idea in 1976, and later schemes made it practical.

A digital signature is the main use here. You sign a message with your private key and produce a short value called the signature. Anyone with your public key can check that the signature matches the message. A match proves two things: the message was not changed, and the signer holds the private key. Nobody can forge a signature without the private key, and the private key cannot be worked out from the public key.

So your public key, or a hash of it, can serve as your name. An address on Bitcoin or Ethereum is exactly this: derived from a public key. Nobody had to approve it. You create it by generating random numbers on your own device.

Compare this with the passwords of the earlier section. A password is a shared secret: both you and the server know it, so a server breach exposes it. With a key pair, the server holds only the public key, which is useless to an attacker.

Proving Control: Challenge And Response

How do you prove you hold a private key without revealing it? The standard method is challenge and response. The verifier sends a random value called a nonce. You sign it, together with context such as the website name, and return the signature. The verifier checks it against your public key.

The random nonce prevents replay: an attacker who recorded an earlier signature cannot reuse it, because the challenge is new each time. Including the website name stops a fake site from collecting signatures meant for the real one.

This is how 'Sign in with Ethereum' works, which lets a wallet log you in to a website with a signed message. The site stores no password. It sees a public key and a valid signature.

Challenge And Response

Verifier sends a fresh random challenge
Holder signs it with the private key
Verifier checks with the public key
Access granted for this session only

The private key never leaves the holder and the challenge is never reused.

Decentralized Identifiers

A raw public key is awkward to use as a name. It has no history, no way to rotate when a key is compromised, and no place to say how to contact you. The World Wide Web Consortium (W3C) published a standard for decentralized identifiers, or DIDs, to give keys a better wrapper.

A DID is a string with three parts, such as did:example:123abc. The first part says it is a DID. The second names the method, which says which system manages this kind of DID: a blockchain, a website, or a peer network. The third is a method-specific identifier. Resolving a DID, using the rules of its method, returns a DID document: a small data file listing the public keys linked to that identifier, the actions each key may perform and, optionally, service endpoints.

The controller of a DID can update its document, for instance replacing an old key with a new one, while the identifier itself stays the same. Rotation is therefore possible without changing your name. Different methods store documents in different places, so a DID may rely on a blockchain, on a web domain, or on nothing but the key itself.

Ed25519 Sizes

bytes

A whole identity and its proof fit in less space than this sentence. Source: RFC 8032

Verifiable Credentials

A key proves that the same person is back. It does not prove anything about that person, such as being over 18 or holding a degree. Claims about a subject come from other parties. The W3C Verifiable Credentials standard describes how to make such claims checkable.

Three roles appear. The issuer, such as a university, creates a credential: a signed statement that a subject holds some property. The holder, the student, keeps the credential in a wallet. The verifier, such as an employer, asks the holder to present it. The verifier checks the issuer's signature against the issuer's public key, found through the issuer's DID, and checks that the credential has not been revoked.

The verifier talks to the issuer's published key but not to the issuer in real time, so the issuer does not learn where the holder shows the credential. Holders may also reveal only needed parts. Some credential formats support selective disclosure, which shows a single attribute, for instance 'over 18', without exposing a full date of birth. Zero-knowledge proofs push this further and are the subject of next week.

Notice what has not been decentralized: trust in the issuer. A credential is only as meaningful as the issuer's reputation. A verifier decides which issuers it accepts.

Four Ways To Log In

Method	Secret shared with server?	Phishable?
Password	Yes, as a hash	Yes
Key pair signature	No, only public key	Harder
Passkey	No, only public key	Bound to the site
Verifiable credential	No, you present proofs	Depends on wallet

Moving from shared secrets to signatures removes a whole class of leaks. Source: Course synthesis; W3C WebAuthn and Verifiable Credentials specifications

Passkeys

Passkeys bring public key identity to everyday logins. Based on the FIDO2 and WebAuthn standards, a passkey is a key pair created for one website. The private key stays on your device, protected by your fingerprint, face or device PIN. The website stores the public key.

To log in, the website sends a challenge. Your device asks you to unlock it, signs the challenge together with the site's domain and returns the signature. The unlock step stays local, so your fingerprint never leaves the device.

Passkeys resist phishing. Because the signature covers the real domain, a lookalike site cannot use it. There is also no password to steal in a data breach, since the server holds only public keys.

Many platforms sync passkeys across a user's devices through an account at Apple, Google or a password manager, which makes recovery easy but brings a provider back into the picture. Passkeys are a good example of the compromise most people accept: strong cryptography with practical recovery.

Self-Sovereign Identity And Its Trade-Offs

Self-sovereign identity, or SSI, is the idea that individuals hold and control their own identifiers and credentials, with no required intermediary. DIDs and verifiable credentials are its building blocks. The appeal is real: portability across services, less data stored in company databases, and users who decide what to share.

The costs are equally real. Key loss is the hardest. If you lose your private key and nobody can help you, you lose the identity. If someone steals the key, they are you. Solutions include backups, social recovery, where chosen friends or devices can together restore access, and hardware keys. Each solution reintroduces some trust in people or devices.

Other problems follow. Revocation, taking back a credential, needs a published list or registry that verifiers can check. Linkability is a concern: reusing the same DID everywhere lets different verifiers connect your activity, so privacy practice calls for separate identifiers per context. Sybil resistance remains unsolved by keys alone, since anyone can make a thousand key pairs. Proof of personhood, which tries to confirm one account per human, is an active area with its own trade-offs between privacy, accessibility and accuracy.

Finally, adoption matters. An identity system is useful only when many verifiers accept it. The wiser question is not whether SSI is better than accounts, but which risks your application can tolerate and who will carry the burden of recovery.

You now hold the main tools of the first half of the course: shared control, unreliable networks, peer discovery, agreement, content addressing and key identity. Next week we turn to privacy and zero-knowledge proofs, which show how to prove a fact without revealing the data behind it.

Key Terms

Private key: A secret number that only its owner holds and that creates signatures.
Public key: A number derived from the private key that anyone can use to check signatures.
Digital signature: A value created with a private key that proves who signed a message and that it was not changed.
Nonce: A random value used once, so that a recorded signature cannot be replayed.
DID: A decentralized identifier: a string that resolves to a document listing the keys of its controller.
Verifiable credential: A signed claim from an issuer about a subject that a verifier can check.
Passkey: A per-site key pair for logins, with the private key kept on the user's device.
Social recovery: A way to restore access to a lost key with help from chosen people or devices.
Selective disclosure: Revealing one attribute of a credential without revealing the rest.

Exercise: Sign, Verify And Tamper

Install Python 3 and run pip install cryptography in a terminal.
Create sign.py and paste the code from the 'Sign and verify in Python' slide. Run it and confirm it prints True.
Change one character of the message after signing, run verify again and observe the failure.
Add a step that prints the public key bytes in hex. This is your identity.
Write a DID document by hand as a JSON file with an id, one public key (use the hex value) and an authentication entry. Use the example method name did:example.
Visit passkeys.io or any site that offers passkeys, create one for a test account and note where the private key lives.