32 lines
1.3 KiB
Markdown
32 lines
1.3 KiB
Markdown
|
# ADR-002: DID Key Method for Node Identity
|
||
|
|
|
||
|
|
**Status**: Accepted
|
||
|
|
**Date**: 2026-03
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
Each Archipelago node needs a cryptographic identity for peer authentication, federation, and verifiable credentials. Multiple DID methods exist (did:web, did:ion, did:key, did:peer).
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
Use `did:key` as the primary DID method.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
### Positive
|
||
|
|
- **Self-contained**: The DID document is derived entirely from the public key — no external resolution needed
|
||
|
|
- **Offline-capable**: Works without internet, aligning with sovereignty principles
|
||
|
|
- **Simple**: No registration, no blockchain, no web server required
|
||
|
|
- **Fast**: DID resolution is a local computation, not a network request
|
||
|
|
- **Ed25519**: Uses Ed25519 keys which are fast, compact, and well-supported
|
||
|
|
|
||
|
|
### Negative
|
||
|
|
- **No key rotation**: The DID is bound to a single key; rotating requires a new DID
|
||
|
|
- **No service endpoints in DID**: Cannot embed service URLs in the DID document itself
|
||
|
|
- **No revocation**: Cannot revoke a did:key without out-of-band mechanisms
|
||
|
|
|
||
|
|
### Mitigation
|
||
|
|
- Use federation trust lists for key management and revocation
|
||
|
|
- Store service endpoints (onion address, pubkey) separately in federation state
|
||
|
|
- Support migration to did:peer or did:web in future versions if key rotation is needed
|