Cross-chain DID interoperability: name-service methods (did:ens ↔ did:sns) - Visibility Only

[chongkan]

Summary

Opened a cross-chain interoperability proposal at veramolabs/did-ens-spec#10 to explore bridging did:ens (Ethereum Name Service) and did:sns (Solana Name Service).

Both methods share the same core pattern — human-readable domain name → W3C DID Document — but resolve through different registries (ENS TEXT records vs. Solana PDA accounts).

SNS Executive Summary, why this matters? - https://github.com/Attestto-com/did-sns-spec/blob/main/did-sns/executive-summary.md

Overlaps

• Both resolve human-readable names (.eth / .sol) to W3C-compliant DID Documents
• Both are blockchain-anchored with decentralized persistence
• Both derive a default verification method from the on-chain owner/controller
• Both support custom service endpoints in the DID Document
• DID syntax follows the same shape: did:<method>[:network]:<name>

Gaps

Area	did:sns	did:ens
CRUD protocol	Fully specified (§5.1–5.4)	Defers to ENS docs, no DID-specific protocol
Key types	Ed25519, secp256k1, ML-DSA-44 (post-quantum)	secp256k1 only
Key rotation	Explicit update operation	Implicit via ownership transfer
Privacy	No PII on-chain, SD-JWT, pairwise DIDs	Warns .eth names leak identity + tx history
Multi-sig	Controller threshold signing	Not specified
Verifiable Credentials	SD-JWT, vLEI, eIDAS/FATF	Not addressed
Encrypted messaging	DIDComm v2	Not addressed
Spec maturity	v1.0, 22/22 W3C requirements	v0.1.1 WIP, production use discouraged

Proposed interop steps (detailed in veramolabs/did-ens-spec#10)

1. alsoKnownAs bidirectional linking — cross-chain identity binding (DID Core §3.1)
2. Shared service endpoint types — DIDCommMessaging, CredentialExchange, LinkedDomains
3. Cross-chain resolution — unified resolver following alsoKnownAs with bidirectional verification
4. Verification method alignment — document accepted key types for cross-chain VP verification

Related

• veramolabs/did-ens-spec#10 — Detailed proposal and gap analysis
• #677 — Onboarding guides + explorer (includes method comparison tooling)
• #676 — Onboarding and ecosystem documentation

[chongkan]

All 8 PRs submitted — full privacy & security alignment

#	PR	Scope	Status
1	#11	Expand CRUD operations	✅ Submitted
2	#13	Key rotation protocol	✅ Submitted
3	#14	Verification method types (Ed25519, JsonWebKey2020, Multikey)	✅ Submitted
4	#12	Service endpoint standardization (DIDComm, CredentialExchange)	✅ Submitted
5	#15	Cross-chain alsoKnownAs linking protocol	✅ Submitted
6	#16	SD-JWT selective disclosure + correlation mitigation	✅ Submitted
7	#17	Pairwise DIDs via ENS subdomains	✅ Submitted
8	#18	Multi-sig controller support via Safe	✅ Submitted

Remaining Ethereum-fundamental gaps (cannot be fixed at spec level):

• On-chain tx history transparency (mitigated by pairwise subdomains + separate wallets)
• Lease expiry → identity reassignment (mitigated by bidirectional alsoKnownAs verification)
• Post-quantum on-chain verification impractical until Ethereum gets PQ precompiles (ML-DSA-44 documented as JsonWebKey2020 type for off-chain use)

If all 8 PRs merge, did:ens reaches functional parity with did:sns for cross-chain credential exchange, with documented limitations for the Ethereum-specific constraints.

[chongkan]

Platform-level mitigations for Ethereum-fundamental constraints

The 3 gaps that can't be fixed at the spec level can be handled at the application/platform layer. These patterns are applicable to any implementation integrating did:ens alongside other DID methods:

1. Transaction history transparency

• Use did:ens as a linked secondary identity (via alsoKnownAs), not the primary credential anchor. Credentials bind to a purpose-built DID on a chain with less tx exposure.
• Enforce pairwise subdomains (Define unified versioning system for machine and human readable definitions. #17) per verifier relationship — the root ENS name is never shared with verifiers, only <hash>.alice.eth appears in presentations.
• Vault-mediated presentations — the VP contains only SD-JWT disclosed claims. The verifier uses the DID as a key reference, never needs to browse on-chain history.

2. Lease expiry → identity reassignment

• Lease monitor — query ENS nameExpires() for all linked did:ens identities. Warn at 90/30/7 days. Auto-flag alsoKnownAs links as unverified on expiry.
• Bidirectional verification at presentation time — resolve both DID Documents and confirm mutual alsoKnownAs (Refactor Github Actions #15). If the ENS name changed hands, the new owner's DID Document won't reference the original linked DID → verification fails.
• Credential binding to the non-expiring DID — issue credentials to the primary DID (e.g. did:sns, which has no lease). The ENS link is an auxiliary assertion, not the credential anchor. Credentials survive ENS expiry.
• Grace period — ENS has a 90-day grace period. Treat the DID as degraded during this window (presentations accepted but flagged).

3. Post-quantum on-chain verification

• Off-chain verification — all VP verification happens server-side, where ML-DSA-44 is supported natively. When a did:ens holder adds an ML-DSA-44 key via JsonWebKey2020 TEXT record (Add initial registration requirements for registries. #14), the verifier handles it off-chain.
• Hybrid signatures — credentials carry dual signatures: secp256k1 (Ethereum-compatible) + ML-DSA-44 (post-quantum). Smart contracts verify the classical sig; the platform verifies the PQ sig.
• Forward-compatible — when Ethereum adds PQ precompiles, the key types are already documented in the did:ens spec. Switch from off-chain to on-chain verification without credential re-issuance.

These mitigations ensure did:ens can participate in cross-chain credential exchange at production quality, with the primary DID method compensating for Ethereum's constraints.

[chongkan]

Proposed architecture: Dual-DID with primary/linked roles

To make this concrete — here's the architecture we're implementing for cross-chain did:ens ↔ did:sns interoperability. We believe this pattern generalizes to any name-service DID pair where one chain has stronger privacy/security guarantees than the other.

Core principle: one DID carries the weight, the other extends the reach

┌──────────────────────────────────────────────────┐
│               Platform / Wallet                  │
├──────────────────────────────────────────────────┤
│                                                  │
│  PRIMARY DID (did:sns)      LINKED DID (did:ens) │
│  ├─ Credential anchor       ├─ alsoKnownAs link  │
│  ├─ SD-JWT issuer           ├─ Pairwise subs     │
│  ├─ Post-quantum native     ├─ Ed25519 via TEXT  │
│  ├─ No lease expiry         ├─ Lease monitor     │
│  ├─ Vault encryption        ├─ Off-chain verify  │
│  └─ 2-of-2 key splitting   └─ Safe multi-sig     │
│                                                  │
│  ┌──────────────────────────────────────────┐    │
│  │         Cross-Chain VP Verification      │    │
│  │  1. Resolve primary DID                  │    │
│  │  2. Extract alsoKnownAs → linked DID     │    │
│  │  3. Resolve linked DID                   │    │
│  │  4. Bidirectional alsoKnownAs check      │    │
│  │  5. Lease expiry check (if applicable)   │    │
│  │  6. SD-JWT signature + key binding       │    │
│  │  7. PQ signature (off-chain)             │    │
│  └──────────────────────────────────────────┘    │
│                                                  │
└──────────────────────────────────────────────────┘

Why dual-DID instead of single-DID?

Every chain has trade-offs. No single DID method covers all requirements at production quality:

Requirement	Ethereum (did:ens)	Solana (did:sns)
Human-readable names	✅ .eth	✅ .sol
Tx privacy	❌ Fully transparent	✅ Purpose-built account
Identity persistence	❌ Lease-based (annual)	✅ Rent-exempt (permanent)
Post-quantum on-chain	❌ No precompiles	✅ ML-DSA-44 native
Ecosystem reach	✅ Largest Web3 ecosystem	⚠️ Growing
Smart contract wallets	✅ Safe multi-sig mature	⚠️ Squads (newer)
Gas costs	❌ $2-20 per TEXT update	✅ ~$0.001 per tx

The dual-DID architecture lets users leverage the strengths of both chains:

• Ethereum users get cross-chain credential access without switching chains
• Solana users get Ethereum ecosystem reach without Ethereum's privacy trade-offs
• Credentials bind to the stronger anchor (did:sns) but are presentable via either DID
• Verifiers on either chain can verify presentations through the alsoKnownAs bridge

How credentials flow cross-chain

Issuer                    Holder                    Verifier
  │                         │                         │
  │  issue SD-JWT to        │                         │
  │  did:sns:alice.sol ───► │                         │
  │                         │                         │
  │                         │  present VP via         │
  │                         │  did:ens:<hash>.alice.eth │
  │                         │ ──────────────────────► │
  │                         │                         │
  │                         │         resolve did:ens │
  │                         │         extract alsoKnownAs
  │                         │         resolve did:sns │
  │                         │         bidirectional ✓ │
  │                         │         verify SD-JWT ✓ │
  │                         │         lease check ✓   │
  │                         │                         │
  │                         │  ◄── accepted ──────── │

The credential was issued to did:sns but presented via a pairwise did:ens subdomain. The verifier never sees the root alice.eth (tx privacy preserved) and never needs Solana infrastructure (chain-agnostic verification via alsoKnownAs resolution).

Generalizable pattern

This architecture isn't specific to did:ens + did:sns. It applies to any pair where:

• Primary DID = stronger privacy/security guarantees, credential anchor
• Linked DID = broader ecosystem reach, user-facing identity

Examples: did:web (primary) + did:ens (linked), did:sns (primary) + did:key (linked for ephemeral sessions), or even did:ens (primary) + did:ens on L2 (linked for gas savings).

The key is that alsoKnownAs + bidirectional verification + SD-JWT selective disclosure make the cross-chain bridge trustworthy without requiring either chain to change its fundamentals.

[chongkan]

did:pkh interoperability — 5 PRs submitted

Opened w3c-ccg/did-pkh#38 and submitted 5 PRs to position did:pkh as a cross-chain cryptographic bridge:

#	PR	Scope
1	#39	alsoKnownAs cross-chain identity linking
2	#40	SD-JWT selective disclosure guidance
3	#41	Cross-chain verification examples (did:pkh ↔ did:sns ↔ did:ens)
4	#42	Update Solana verification key type (2018 → 2020, addresses their #12)
5	#43	Optional service endpoint discovery (backwards compatible)

did:pkh's role in the architecture: Universal key-proof layer. It wraps any blockchain address into a DID, enabling verifiers to confirm key ownership without chain-specific resolvers. Combined with alsoKnownAs, it bridges to richer methods (did:ens, did:sns) for services, key rotation, and selective disclosure.

Running total: 8 PRs on did:ens + 5 PRs on did:pkh = 13 cross-chain interoperability contributions.