Identity Layer
ACK-ID chose did:web for a reason. This page evaluates six methods against compliance requirements — resolution latency, regulatory alignment, and ecosystem fit.
ACK-ID currently uses did:web for DNS and HTTPS anchoring, aligned with corporate infrastructure standards and enterprise deployment patterns. This choice was deliberate: did:web provides immediate resolution, integrates with existing DNS infrastructure, and requires no external blockchain dependency.
The ACK roadmap explicitly calls for "additional DID method support" — expanding beyond did:web to accommodate diverse agent topologies, regulatory jurisdictions, and ecosystem partnerships. Each DID method carries different compliance trade-offs: DNS hijacking risk for did:web, resolution latency for did:ion, ecosystem maturity for did:hedera, and revocation challenges for did:key.
This evaluation charts the compliance landscape. For each method, we assess ACK-ID fit (immediate deployment readiness), compliance strength (regulatory coverage), and critical weakness (the trade-off that shapes deployment context).
| Method | ACK Fit | Compliance Strength | Critical Weakness |
|---|---|---|---|
| did:web | Current ACK-ID standard | Corporate DNS anchor, HTTPS verifiable, immediate resolution (2ms) | DNS can be hijacked; revocation requires centralized control |
| did:hedera | Strong candidate | Enterprise-grade backing (Google, IBM, Deutsche Telekom), immutable ledger | Smaller developer ecosystem; Hedera governance concentration |
| did:key | Ephemeral sessions | Zero-latency (2ms), no external anchor needed, maximum privacy | No revocation mechanism, no key rotation, unsuitable for long-lived credentials |
| did:ion | Archival identity | Bitcoin-anchored immutability, Microsoft backing, Sidetree standard | 1800ms resolution latency; batch anchoring creates timing uncertainty |
| did:pkh | Wallet-native | Bridges existing blockchain addresses to DIDs, accounts-agnostic | Read-only (no key rotation), depends on underlying chain liveness |
| did:ethr | Ethereum ecosystem | ERC-1056 registry, broad tooling, chain-native key management | Gas costs for every key rotation; Ethereum mainnet dependency |
Interactive Demo
Resolve any DID method and compare resolution latency, document structure, and ACK-ID service endpoint compatibility.
Resolve any W3C Decentralized Identifier to inspect its DID Document, verification methods, and service endpoints across six major DID methods.
Supports did:web · did:hedera · did:key · did:ion · did:pkh · did:ethr — W3C DID Core v1.1
Select a DID method above or enter a DID string to explore its W3C-compliant document structure
Architecture
Five-layer architecture from blockchain anchor (L1) through credential (L4) to application (L5). Each layer enforces compliance constraints: L1 anchors identity immutability, L2 resolves credentials, L3 verifies signatures, L4 encodes compliance constraints, L5 gates transaction access.
| Regulation | Requirement | DID Method Satisfaction |
|---|---|---|
| GENIUS Act §4 | Entity identification and DID resolution | All methods satisfy this via W3C DID Core resolution. did:web, did:hedera, did:ion preferred for immutability guarantee. |
| FATF Travel Rule R.16 | Originator and beneficiary identification (verified without exposing PII) | did:web (corporate anchor), did:hedera (immutable ledger), did:ion (Bitcoin-anchored) provide non-repudiable proof. did:key unsuitable (no revocation). |
| BSA Beneficial Ownership | Identify natural persons behind legal entities via delegation chain | Requires revocation and key rotation: did:web, did:hedera, did:ethr satisfy. did:key does not (no revocation). |