DID Key Vs DID Web For Verifiable Credentials

A Verifiable Credential’s issuer identifier has to resolve to a public key somehow — did:key embeds the key directly in the identifier so no network lookup is needed, while did:web ties resolution to a domain you control, which is why AuthiChain’s protocol spec uses did:key by default.

Why AuthiChain

• did:key needs no DNS, hosting, or network call to resolve — the public key is the identifier, which is what makes offline verification possible at all
• did:web ties portability to a domain: lose the domain and every credential issued under that method stops resolving
• protocol/SPEC.md §5 step 2 resolves the issuer key from did:key with zero network access, matching the spec’s offline-verification requirement

How it works

Issue a unique identifier per unit, anchor its record on-chain for tamper-evidence, and let anyone verify it with a single scan. Plans start at $49/mo.

FAQ

Why not use did:web since we already control a domain?

You can — the spec does not forbid it. But did:web makes verification depend on your DNS and hosting staying reachable, which works against the goal of a verifier reaching a verdict without contacting anyone.

Does did:key support key rotation?

Not on its own — a new key is a new identifier. That gap is part of what credentialStatus and revocation, planned for v0.2, are meant to address.