DID-Based Authentication: Cryptographic Proof Instead of Passwords

Introduction

Passwords are a liability for the services that store them. Each credential database is a target for attackers, and each "forgot password" flow adds an attack surface. DID-based authentication replaces shared secrets with cryptographic proof. You prove that you control the private key for a public key in your DID document. The verifier does not store a secret.

How Password Authentication Fails

The basic problem with passwords is that they are shared secrets. The server must store a value (ideally a hash) to verify the password later. This design has structural weaknesses:

• Credential stuffing: Many users use the same password on many services. Attackers try the credentials from one breach on other sites (OWASP Credential Stuffing Prevention).
• Phishing: A fake site can trick a user into a password entry. The password itself is the credential, so the attacker can use it at once. NIST does not accept an authenticator with manual entry as phishing-resistant, because manual entry does not bind the output to the session (NIST SP 800-63B-4).
• Storage liability: Each password-hash database is a target. A unique salt stops attacks with precomputed tables (OWASP). But an attacker with a stolen database can still guess passwords offline, and weak passwords fail even against modern memory-hard hashes (OWASP Password Storage).
• Recovery complexity: Password reset flows often send a token by email (OWASP Forgot Password). The email account then becomes the real authentication factor, with its own attack surface.

DID Authentication Model

DID-based authentication uses a challenge-response protocol.

The Flow

1. The client starts: The wallet of the user presents the DID of the user to the service.
2. The service sends a challenge: The service makes a random nonce and sends it to the client. The service asks the client for a signature over the nonce.
3. The client signs: The wallet signs the challenge with the private key of a verification method in the authentication relationship of the DID document.
4. The service resolves the DID: The service resolves the DID to get the DID document and its public keys.
5. The service verifies: The service checks the signature against the resolved public key. If the signature is valid, the service authenticates the user.

A signed nonce alone does not stop phishing. The signed message must also identify the service. NIST calls this property verifier name binding. With this property, a fake site cannot use the signature at the real service.

What the Service Stores

The service must store only the DID string of the user, which is a public identifier. It stores no secrets, no hashes, and no password recovery tokens. If attackers breach the service database, they get only a list of public identifiers. They cannot log in with these identifiers without the private keys.

But a DID is a correlatable identifier. If a user gives the same DID to each service, the list can link that user across services. DID Core describes pairwise DIDs (one DID for each relationship) as a way to reduce this risk (DID Correlation Risks).

Technical Implementation

DID Authentication with SIOP (Self-Issued OpenID Provider)

SIOP v2 changes OpenID Connect so that the user controls their own OpenID Provider. The subject identifier can be a DID or a JWK thumbprint (Subject Syntax Types). Thus, DID authentication can work with the current OIDC infrastructure:

• The wallet of the user is its own OpenID Provider.
• The authentication response contains a signed ID token. The sub claim of the token is the DID of the user.
• The relying party verifies the token against the DID document. It also checks that the nonce and aud claims match its request (Self-Issued ID Token Validation).
• A team with current OIDC libraries can add SIOP support to them. The team must add DID resolution and the SIOP validation rules.

Key Management

The security model moves from the service to the key management of the user:

• Hardware-backed keys: Secure hardware in mobile devices and hardware tokens can hold the private key. This hardware makes key extraction very difficult. For example, the Android Keystore can bind keys to secure hardware, and the Apple Secure Enclave is isolated from the main processor.
• Key rotation: If an attacker gets a key, the user updates the DID document with a new key. For a Bitcoin-anchored DID, a Bitcoin transaction anchors the update. The user does not need to contact each service, because each service identifies the user by the DID, not by the key.
• Recovery keys: Some DID methods, such as ION (on the Sidetree protocol), have a separate recovery key. The Sidetree specification advises clients to keep update keys and recovery keys apart. Each key needs protections that match its risk (Update vs Recovery Keys). With a recovery key, a user can get control back without a central reset flow. Other methods use a different model. For example, did:btcr2 has no separate recovery key: a key in the capabilityInvocation relationship authorizes each update (did:btcr2 Update).

Comparison with Current Alternatives

vs. OAuth/Social Login

Social login (OAuth 2.0 with OpenID Connect on top) gives the identity role to a provider. That provider can revoke access, track use, and go offline. DID authentication removes the dependency on one identity provider. It adds a dependency on DID resolution for the DID method that the user chooses.

vs. Passkeys/WebAuthn

Passkeys are a large improvement over passwords. WebAuthn binds each credential to the domain of the website, and this property gives phishing resistance (NIST SP 800-63B-4). In the past, it was difficult to move passkeys between platform ecosystems (Apple, Google, Microsoft).

The FIDO Alliance published the Credential Exchange Format (CXF) 1.0 as a Proposed Standard in August 2025. As of September 2026, the Credential Exchange Protocol (CXP) is still a Working Draft (FIDO specification list).

The difference that stays is the control model. The DID method defines how a DID works, and the user manages the DID. The user controls the keys directly, not through a credential provider.

vs. Client Certificates

TLS client certificates give similar cryptographic authentication. In practice, a certificate authority (CA) usually issues them, and the server validates them through that CA (the PKI method). This model needs CA operations for issuance and revocation. RFC 8705 (OAuth 2.0 Mutual-TLS) also defines a self-signed variant that the server validates against keys that the client registered before. The user makes and manages a DID, and DID resolution (not a CA) binds the identifier to the key.

Migration Strategy

You do not need to remove your current authentication at once:

1. Add DID authentication as an option next to your current login methods.
2. Link DIDs to current accounts: Let users connect a DID to their current account.
3. Give users a reason to change: Offer benefits to users who log in with a DID (for example, no 2FA prompts and faster login).
4. Remove passwords: When enough users use DID authentication, stop password-based login.

Conclusion

DID-based authentication removes one major cause of authentication breaches: shared secrets on servers. With cryptographic proof of key control, services store less sensitive data, and users get more control. The tradeoff is that the complexity of key management moves to the user. The ecosystem does not have a complete solution for this problem yet.

The base standards exist:

• DID v1.0 is a W3C Recommendation, and DID v1.1 is a W3C Candidate Recommendation (as of September 2026).
• The OpenID Foundation approved SIOP v2 as an Implementer's Draft in February 2022. As of September 2026, SIOP v2 is not a Final specification.

The infrastructure continues to mature, and you can do the migration in small steps.