How Sign in with Dash works

1. The website creates a short-lived, domain-bound login request and shows a QR (or link).
2. Your authenticator fetches the request over HTTPS, shows the domain and action, and asks you to approve.
3. You approve; the phone signs a canonical challenge with an eligible Dash identity authentication key (HIGH).
4. The website verifies the signature and checks Dash Platform (identity keys + DPNS name). On this demo in simulator mode, fixtures stand in for Platform.
5. Only the browser that started the login (binding cookie) can finish and receive a session cookie.

What it is not

• Not a password or email magic link
• Not Yappr-style key transfer into the website (this site never holds your keys)
• Not phishing-proof for QR forwarding in the MVP — only approve logins you started
• Not mainnet-ready

Account model on this demo

Accounts are identity-bound: the Dash identity ID is the stable key; the DPNS name is a public handle. Session cookies last for the browser session only.

Recommended policy for website implementors

Use identity binding for current integrations. Match accounts by network and Dash identity ID, and attach administrator roles to that identity or its local account. A name is a verified handle: selling or transferring it must not give its buyer the original identity's website account or permissions.

Defer name binding. The protocol defines it, but safe account ownership handover is not yet implemented. Continue checking current name ownership and active signing keys. After transferring a name, a user needs another name they still control to sign in; never recover or merge accounts just because names match.