The simplest P2P identity is a cryptographic key pair. Your identity is your public key (or a hash thereof):

Ed25519: fast, compact signatures (64 bytes), 32-byte keys. Used by libp2p peer IDs, SSB feed IDs, Hypercore log keys, and Nostr public keys.

SECP256k1: used by Bitcoin, Ethereum, and Nostr (where keys double as crypto wallet identities).

RSA: legacy; still supported by older libp2p peers but being phased out due to large key sizes.

This is a self-certifying identity: no registration, no authority, no permission needed. Anyone can generate a key pair and start participating. The trade-off is that identities are opaque (public keys aren't human-readable) and Sybil attacks are cheap—creating a new identity costs nothing.

Long-lived keys are a liability—compromise means permanent identity loss. This is especially painful for SSB users whose feed ID is their key. Solutions:

Key delegation chains: a root key signs a delegation to a new active key; the chain proves continuity. Anyone who trusts the root key transitively trusts the delegated key.

Key revocation: publish a signed revocation record via DHT or append-only log. Revocation is hard in P2P because there's no guaranteed delivery.

Multi-device: delegate sub-keys per device, revocable independently. This is how Matrix cross-signing works.

Key stretching: derive multiple purpose-specific keys from a single master secret.

DIDs are a W3C standard for portable, self-sovereign identity:

A DID (e.g., did:key:z6Mk...) resolves to a DID Document containing public keys, service endpoints, and authentication methods.

DID methods define how resolution works: did:key is purely cryptographic (the DID is the key), did:web uses DNS, did:plc (used by Bluesky/AT Protocol) uses a registry for key rotation.

Verifiable Credentials (VCs): signed claims about a DID holder (e.g., "this DID belongs to organization X"), enabling trust without central identity providers. VCs can be presented selectively, revealing only needed attributes.

DIDs bridge the gap between raw cryptographic keys and human-meaningful identity.

Capabilities answer "what can this peer do?" rather than "who is this peer?". This inversion is powerful for P2P where identity is cheap but authorization matters:

Object capabilities (ocaps): possession of a capability token grants access; there is no ambient authority. Unforgeable references. The classic formulation from operating systems research, applied to distributed systems.

UCAN (User Controlled Authorization Networks): JWT-like tokens where each holder can attenuate (restrict) and delegate capabilities to others, forming a delegation chain. Used in Fission and emerging IPFS tooling. Verifiable offline—no need to contact an authorization server.

Macaroons: bearer tokens with caveats (conditions) that can be appended by any holder to restrict scope. Used by Lightning Network and some API authorization systems.

Tahoe-LAFS capabilities: read-caps, write-caps, and verify-caps as unguessable cryptographic tokens. A clean practical implementation of the ocap model.

Capability-based systems embody least privilege: you grant exactly the access needed, and delegation is explicit and attenuatable.

Allowlists: simple but static; the author maintains a list of permitted keys. Used by private Hypercore feeds.

Reputation systems: peers accumulate trust scores from interactions. GossipSub scoring and BitTorrent tit-for-tat are reputation-based.

Social trust (web of trust): SSB uses the follow graph for replication scope—if nobody follows you, you're effectively excluded.

Stake-bonded permissions: economic deposits as skin-in-the-game; slashing for misbehavior. Common in blockchain P2P (Filecoin storage deals, Ethereum validators).

Identity keys sign content-addressed mutable pointers (IPNS records, signed heads). They authenticate transport connections via Noise/TLS handshakes. DHTs store and discover identity records. Identity governs who can write in collaborative sync and who can publish to PubSub topics. Privacy and Anonymity explores the tension between strong identity and unlinkability. Security Threats addresses Sybil attacks that exploit cheap identity creation. Compliance addresses accountability and the relationship between pseudonymous identity and legal obligations. Testing must cover key rotation scenarios and delegation chain validation.