Context
We maintain the did:sns spec (Solana Name Service → DID Documents). Since did:pkh already supports Solana addresses (solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ), there's a natural bridge: the same Ed25519 key that backs a did:sns:alice.sol can be represented as did:pkh:solana:...:CKg5d12J....
This makes did:pkh uniquely positioned as a universal key-proof layer — verifying that a blockchain address controls a key, while richer DID methods (did:sns, did:ens, did:web) provide the full lifecycle features (updates, services, revocation).
The opportunity
did:pkh's minimalist generative design is a strength, not a gap. It doesn't need to become a full-lifecycle method. Instead, it can serve as the cryptographic bridge between chains:
did:sns:alice.sol ──alsoKnownAs──► did:pkh:solana:...:CKg5d12J...
│
did:ens:alice.eth ──alsoKnownAs──► did:pkh:eip155:1:0xABC...
A verifier who only supports did:pkh can still verify that a did:sns credential holder controls the underlying Solana key — without needing a did:sns resolver.
Proposed contributions
We'd like to submit a series of small PRs that respect did:pkh's minimalist philosophy:
| # |
Scope |
Changes to generative model? |
| 1 |
alsoKnownAs support — link did:pkh to richer DID methods |
No — additive property in generated doc |
| 2 |
SD-JWT credential guidance in Privacy section |
No — VC-layer recommendation |
| 3 |
Cross-chain verification examples (did:pkh ↔ did:sns ↔ did:ens) |
No — documentation |
| 4 |
Update Solana verification key type (2018 → 2020) + test vectors |
Yes — minor type update (addresses #12) |
| 5 |
Optional service endpoint discovery via companion registry |
Extends — opt-in companion, not core change |
None of these change did:pkh's core "generative, read-only" nature. They add interoperability guidance and bring the spec up to date.
Related
Context
We maintain the did:sns spec (Solana Name Service → DID Documents). Since did:pkh already supports Solana addresses (
solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ), there's a natural bridge: the same Ed25519 key that backs adid:sns:alice.solcan be represented asdid:pkh:solana:...:CKg5d12J....This makes did:pkh uniquely positioned as a universal key-proof layer — verifying that a blockchain address controls a key, while richer DID methods (did:sns, did:ens, did:web) provide the full lifecycle features (updates, services, revocation).
The opportunity
did:pkh's minimalist generative design is a strength, not a gap. It doesn't need to become a full-lifecycle method. Instead, it can serve as the cryptographic bridge between chains:
A verifier who only supports did:pkh can still verify that a did:sns credential holder controls the underlying Solana key — without needing a did:sns resolver.
Proposed contributions
We'd like to submit a series of small PRs that respect did:pkh's minimalist philosophy:
alsoKnownAssupport — link did:pkh to richer DID methodsNone of these change did:pkh's core "generative, read-only" nature. They add interoperability guidance and bring the spec up to date.
Related