What You Can Do By The End

• Explain key pairs as identity
• Sign and verify a message in Python
• Describe DIDs and verifiable credentials
• Explain how passkeys work
• Weigh self-sovereign identity trade-offs

Accounts Today

• Identity lives in a company's database
• Password is a secret both sides know
• A breach leaks the secret
• A closed account removes the identity

Key Pairs

• Private key: secret, held by you
• Public key: shared with everyone
• Diffie and Hellman published the idea in 1976
• The private key cannot be worked out from the public key

Digital Signatures

• Sign a message with the private key
• Anyone checks it with the public key
• A match proves the signer and an unchanged message
• No private key, no valid signature

message  --sign(private key)-->  signature
message + signature + public key  -->  valid or invalid

Sign And Verify In Python

• Needs pip install cryptography
• Ed25519 is a modern signature scheme
• Verify raises an error when the data was altered

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.exceptions import InvalidSignature

key = Ed25519PrivateKey.generate()
pub = key.public_key()
msg = b'I agree to the proposal'
sig = key.sign(msg)
try:
    pub.verify(sig, msg)
    print(True)
except InvalidSignature:
    print(False)

A Public Key As A Name

• Create it yourself with random numbers
• No registry, no approval
• Bitcoin and Ethereum addresses derive from public keys
• The server holds only the public key

Challenge And Response

• Verifier sends a fresh random nonce
• You sign it with the site name included
• The nonce stops replay of old signatures
• The site name stops lookalike sites

site   -> user: nonce 8c1f...
user   -> site: sign(nonce + 'example.org')
site checks signature with stored public key

Why A Bare Key Is Not Enough

• No history or context
• No way to rotate a compromised key
• No contact information
• Needs a wrapper: the DID

Decentralized Identifiers

• Format: did:method:identifier
• The method says where the document is managed
• Resolving a DID returns a DID document
• The document lists keys, uses and services

{
  "id": "did:example:123abc",
  "authentication": [{
    "id": "did:example:123abc#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123abc"
  }]
}

Issuer, Holder, Verifier

• Issuer signs a claim about a subject
• Holder keeps it in a wallet
• Verifier asks for it and checks the signature
• Issuer's key is found through its DID

Issuer --credential--> Holder --presentation--> Verifier
                                   Verifier checks Issuer's key

Showing Less

• Reveal one attribute, such as over 18
• Hide the full date of birth
• Some formats support this directly
• Zero-knowledge proofs go further (next week)

Passkeys

• One key pair per website
• Private key stays on the device
• Fingerprint or PIN unlocks it locally
• The signature covers the real domain, which resists phishing

The Hard Parts Of Self-Sovereign Identity

• Lost key: lost identity
• Stolen key: someone else is you
• Revocation needs a registry to check
• Same DID everywhere lets verifiers link your activity

Sybils And Proof Of Personhood

• Anyone can create a thousand key pairs
• Keys alone do not count humans
• Proof of personhood aims for one account per human
• Trade-offs: privacy, access and accuracy

Recap

• A key pair creates an identity without a registry
• Challenge and response proves control
• DIDs and credentials add stability and claims
• Passkeys bring keys to daily logins
• Recovery is the central design question

Next Week

• Privacy and zero-knowledge
• Prove a fact without revealing the data
• Building on keys, hashes and credentials

Questions And Exercise

• Run sign.py and tamper with the message
• Write a DID document by hand
• Create a passkey on a test account
• Note where the private key lives