⚿

Pearl ID

Sign-in with Pearl — your key is your account. Sign a site's challenge, prove you hold the key, log in as your prl1… address. No passwords. No OAuth.

Your identity key

Your Pearl ID is a BIP-86 key. Its identity is the tweaked keypath x-only pubkey — the same key that controls its PRL address. Sites see your prl1… address as your username.

Stays in this page's memory only. Never sent anywhere. Never written to disk by this page. Signing happens locally.

Sign a login challenge

A site that wants you to log in shows you a domain and a challenge. Paste them here, check the domain is really the site you mean to log in to, and sign. What you hand the site is a credential anyone can verify — and it expires.

"Generate" mints a fresh 256-bit challenge for testing. A real site gives you its own — paste that instead.
Shorter is safer: a leaked credential replays until it expires.

Verify a credential

Standalone verifier — no key needed. Paste any Pearl ID credential: the page recomputes the canonical bytes, checks the 64-bit fingerprint, verifies the BIP-340 signature, recomputes the address from the key (the username really is the key), checks the domain binding and expiry, and rules VALID / INVALID.

Relying-party integration

Add "Sign in with Pearl" to your site in an afternoon. The protocol is four steps; the verifier is twenty lines.

The protocol

  1. Issue: generate 32 random bytes (hex), store them server-side as single-use with a ≤5-minute TTL, and show the user your domain + the challenge.
  2. Collect: the user returns a prl-id credential (this page's Sign-in tab produces one).
  3. Verify: run the snippet below. It checks the signature, the address↔key binding, the domain, and the expiry.
  4. Consume: check the credential's challenge equals the one you issued, then burn it — never accept the same challenge twice. The address field is the user's account id.

Verifier snippet (needs pearl-id.bundle.js → window.PearlID)


          

          
Issuer snippet (node)

          

          

          
Security notes

          
    
            
  • Challenges MUST be ≥128-bit CSPRNG output, single-use, and bound to one domain. Reused challenges are replayable logins.
    • 
            
  • Keep credential lifetimes in minutes. A leaked credential is a bearer token until expires_at.
    • 
            
  • Always pass expectedDomain — a credential for another domain must not log anyone in here.
    • 
            
  • Signatures prove key control, not personhood. If you need humans, that's your problem to solve — the math won't.
    • 
            
  • Phishing: only ever sign challenges on the domain you intend to log in to. This page shows the domain big before signing for exactly that reason.
    •