Date: 2026-02-04 Author: Ray Voelker (with Claude Sonnet 4.5) Status: Authentication Architecture Tags: sqrl, authentication, security, steve-gibson, passwords, patron-privacy
"THIS IS THE WAY EVERYONE LOGS IN. Easy. Simple. Elegant. Perfect." - Ray Voelker, 2026-02-04
I think I may have a very "YOU"-SHAPED thing here.
I'm Ray Voelker, System Administrator for a large public library system in Ohio. You may remember me from Security Now Episode 940 ("When Hashes Collide," September 19, 2023) where I asked about pseudonymization for patron data - how to protect privacy while maintaining statistical utility.
You taught me about using truncated hash outputs (24 bits for ~5,000 patrons) to create plausible deniability through deliberate collisions. That birthday paradox approach was brilliant.
Now I'm building something even better: CHIMPY (Community Hub for Interoperable Modular Platform, Y-factor) - a specification-first platform for public libraries.
And I want SQRL to be THE authentication method. Not "an option". THE default.
Why? Because libraries are democracy's infrastructure, and they need authentication that respects patron privacy by DEFAULT.
This is a "YOU"-shaped problem because:
- It's about PROTOCOLS (you love protocols)
- It's about PRIVACY (you care deeply about privacy)
- It's about PUBLIC INSTITUTIONS (libraries serve everyone)
- It's about ELIMINATING PASSWORDS (your life's work with SQRL)
This document explains why SQRL is perfect for libraries, and why I think CHIMPY + SQRL could change how millions of library patrons authenticate.
Libraries currently use:
- Patron barcodes (14 digits, no security)
- PINs (4-6 digits, easily guessed)
- Passwords (patron forgets, staff resets, repeat forever)
- Email/username (patron doesn't remember which email, locked out)
Problems:
- ❌ Patrons forget passwords - Staff spend hours resetting them
- ❌ Password databases get breached - ILS vendors store passwords (often poorly)
- ❌ Phishing attacks - Fake library emails steal credentials
- ❌ Credential stuffing - Patrons reuse passwords, get compromised
- ❌ No privacy - Vendor requires email, phone, personal info
- ❌ Vendor lock-in - Password database trapped in proprietary ILS
Result: Authentication is a security disaster AND a usability nightmare.
Traditional authentication requires:
- Email address (vendor harvests, sells, leaks)
- Phone number (SMS 2FA, also harvested)
- Personal info (name, address for "verification")
SQRL requires:
- Nothing. Scan QR code. Done.
Patron gets:
- ✅ Anonymous authentication (cryptographic identity, not email)
- ✅ Different identity per library (can't correlate across libraries)
- ✅ Zero personal info collection (GDPR compliance by default)
- ✅ Instant revocation (lost phone? New identity in 30 seconds)
This is patron sovereignty.
Current reality:
- Patron calls: "I forgot my password"
- Staff looks up account, resets password
- Staff emails temporary password
- Patron forgets to check email
- Patron calls again next week
Repeat 50 times per day. Every day. Forever.
With SQRL:
- Patron: "How do I login?"
- Staff: "Scan this QR code"
- Patron: "That's it?"
- Staff: "That's it."
Zero password resets. Zero "forgot password" emails. Zero support burden.
Traditional ILS:
ILS Vendor Database:
- patron_id: 12345
- email: patron@example.com
- password_hash: $2y$10$... (hopefully bcrypt, probably not)
- created: 2015-03-12
Breach:
→ 500,000 patron emails leaked
→ Password hashes cracked
→ Patrons' emails sold to spammers
→ Library's reputation destroyed
With SQRL:
CHIMPY Database:
- patron_id: 12345
- sqrl_public_key: <cryptographic identity>
- created: 2026-02-04
Breach:
→ Public keys leaked
→ Attacker has... public keys (already public!)
→ Zero patron privacy impact
→ Zero password leaks (no passwords exist)
→ Library reputation: FINE
Can't leak what you don't collect. Can't breach what you don't store.
Problem: Consortium ILS tracks patrons across libraries
Traditional consortium:
Patron checks out "The Communist Manifesto" at Library A
→ Recorded in central database with patron email
Patron checks out "Mein Kampf" at Library B
→ Same email, same patron_id, linked records
Consortium admin (or attacker) can see:
→ This patron reads controversial political books across multiple libraries
SQRL solution:
Patron uses DIFFERENT SQRL identity for each library:
Library A:
- sqrl_public_key_A: <identity for Library A>
- Cannot correlate with Library B
Library B:
- sqrl_public_key_B: <different identity for Library B>
- Cannot correlate with Library A
Patron's reading habits across libraries: PRIVATE
This is REAL privacy.
First-time patron registration:
- Patron visits library (physical or website)
- Library displays SQRL QR code
- Patron scans with SQRL app on phone
- SQRL app generates cryptographic identity FOR THIS LIBRARY
- CHIMPY kernel stores public key
- Patron is logged in
No email. No phone. No password. No personal info. 30 seconds. Done.
Subsequent logins:
- Website/app displays SQRL QR code
- Patron scans
- Logged in
Patron experience: "This is SO EASY."
Staff accessing kernel TUI:
tui_authentication:
method: SQRL + 2FA (TOTP)
workflow:
1. TUI displays SQRL QR code on console
2. Staff scans QR with SQRL app
3. SQRL app shows: "Library Kernel TUI - Confirm login?"
4. Staff confirms
5. SQRL app prompts for 2FA (TOTP code)
6. Staff enters 6-digit TOTP
7. Logged into TUI control panel
security:
- SQRL proves identity (cryptographic)
- 2FA proves possession (time-based OTP)
- Audit log shows WHICH staff member logged in
- No password to steal from staff computerSSH access to DANGER tier fields:
ssh_authentication:
method: SQRL + 2FA → time-limited SSH certificate
workflow:
1. Staff authenticates with SQRL + 2FA
2. Kernel generates time-limited SSH certificate (1 hour)
3. Staff uses certificate for SSH access
4. Certificate expires automatically
benefits:
- No long-lived SSH keys
- No passwords
- No keys in ~/.ssh to steal
- Audit trail shows who accessed DANGER fields (DLN, SSN)
- Time-limited (certificate expires)AI agents get SQRL identities too:
ai_agent_registration:
workflow:
1. Library admin registers new AI agent
2. Admin scans SQRL QR for agent identity
3. Agent receives cryptographic identity
4. Agent signs all requests with SQRL signature
benefits:
- No API keys to leak
- No bearer tokens to steal
- Cryptographic proof of agent identity
- Can revoke agent identity instantly
- Audit trail shows which agent did whatAgent makes authenticated request:
# Agent signs request with SQRL identity
response = agent.execute(
operation="patron.read",
params={"barcode": "21234567890123"},
sqrl_signature=agent.sqrl_sign(operation, params)
)
# Kernel verifies:
# 1. Signature is valid (proves request from THIS agent)
# 2. Request wasn't tampered with
# 3. Agent has permission for operation
# 4. Patron allows AI access (patron-level control)DevOps with SQRL:
ansible_authentication:
workflow:
1. Admin authenticates with SQRL + 2FA
2. Ansible playbook runs with admin's SQRL-signed credentials
3. All operations cryptographically signed
4. Audit log shows which admin ran which playbook
benefits:
- No ansible vault passwords
- No SSH keys in git repos
- No secrets.yml to leak
- Cryptographic proof of who did whatAttack Surface:
├── Password database (breach leaks all passwords)
├── Password reset emails (phishable)
├── "Forgot password" flow (social engineering)
├── Password transmission (MITM on non-HTTPS)
├── Password reuse (credential stuffing)
├── Keyloggers (capture password)
├── Shoulder surfing (see password typed)
├── Post-it notes (password written down)
├── Brute force (weak passwords)
└── Rainbow tables (crack password hashes)
SQRL Attack Surface:
Attack Surface:
└── (none - no password exists)
SQRL eliminates THE ENTIRE attack surface.
| Attack Vector | Password Auth | SQRL |
|---|---|---|
| Password theft | ❌ Vulnerable (steal password) | ✅ Impossible (no password) |
| Phishing | ❌ Vulnerable (fake login page) | ✅ Impossible (nothing to steal) |
| Credential stuffing | ❌ Vulnerable (password reuse) | ✅ Impossible (unique crypto key per site) |
| Database breach | ❌ Leak all password hashes | ✅ Nothing to leak (public keys are public) |
| Password reuse | ❌ Common (patrons reuse) | ✅ Impossible (different key per library) |
| Keylogger | ❌ Captures password | ✅ Nothing to capture (QR scan, not typed) |
| Man-in-the-middle | ❌ Can intercept password | ✅ Cryptographic proof (signed challenge) |
| Brute force | ❌ Possible (weak passwords) | ✅ Impossible (256-bit crypto key) |
| Rainbow tables | ❌ Can crack hashes | ✅ Nothing to crack (no password hash) |
| Social engineering | ❌ "What's your password?" | ✅ Nothing to give (no password to reveal) |
| Post-it notes | ❌ Password written down | ✅ Nothing to write (phone has SQRL app) |
| Shoulder surfing | ❌ See password typed | ✅ See QR scan (public, not secret) |
Every. Single. Password. Attack. Eliminated.
Libraries are not profit-driven. They serve the public good.
- ✅ Don't sell patron data (unlike vendors)
- ✅ Don't track patrons for advertising
- ✅ Don't harvest emails/phones
- ✅ Committed to patron privacy (ALA values)
SQRL aligns with library values: Privacy by default, not profit by surveillance.
Libraries serve:
- Children (parents don't want kids creating accounts with email)
- Elderly (forget passwords, don't use email regularly)
- Low-income (may not have consistent email access)
- Immigrants (ESL, unfamiliar with English password requirements)
- Homeless (no fixed email/address for password recovery)
SQRL works for ALL:
- ✅ No email required (scan QR, done)
- ✅ No complex password rules (no password!)
- ✅ No "forgot password" email (nothing to forget)
- ✅ Works on any smartphone (iOS, Android, even old phones)
SQRL is MORE accessible than passwords.
Public libraries:
- 50,000+ patrons (large library)
- 2-5 IT staff (if lucky)
- Tiny security budget (public funding)
- Can't afford password breach lawsuits
SQRL eliminates:
- ✅ Password reset support burden (staff time)
- ✅ Password database security costs (no database to secure)
- ✅ Breach liability (can't leak what you don't collect)
- ✅ Password policy enforcement (no passwords to enforce)
SQRL reduces costs AND improves security.
Library consortia:
- 50-200 libraries
- Shared ILS (or federated)
- Patrons use multiple libraries
- Privacy concerns (cross-library tracking)
SQRL enables:
- ✅ Per-library identities (patron privacy preserved)
- ✅ Federation without correlation (different keys per library)
- ✅ No central password database (no single point of breach)
- ✅ Library sovereignty (each library controls own auth)
SQRL is PERFECT for federated library systems.
Goal: Prove SQRL works for libraries
CHIMPY Kernel (Rust):
├── SQRL authentication (primary)
├── Patron accounts (SQRL public keys, no passwords)
├── Staff TUI (SQRL + 2FA)
├── SSH access (SQRL + time-limited certificates)
└── AI agents (SQRL signatures)
Deployment:
├── Pilot library (1,000 patrons)
├── Document: "6 months, zero password resets"
├── Metrics: Support burden reduced 80%
└── Case study: "Patron privacy + usability"
Goal: Multi-library federation with SQRL
Consortium (50 libraries):
├── Each library: CHIMPY kernel
├── Each patron: Different SQRL identity per library
├── Federation protocol: SQRL-signed requests
├── Privacy preserved: No cross-library correlation
Metrics:
├── 50,000+ patrons on SQRL
├── Zero password database breaches
├── 90% reduction in authentication support tickets
└── Patron satisfaction: "This is SO EASY"
Goal: SQRL as standard library authentication
Adoption:
├── 500+ libraries using CHIMPY + SQRL
├── 5M+ library patrons on SQRL
├── ALA recommendation: "SQRL for patron privacy"
├── ILS vendors: Adding SQRL support (competitive pressure)
Impact:
├── Millions of patrons with password-free authentication
├── Zero password databases to breach
├── Libraries: "We don't collect emails/passwords anymore"
└── Patrons: "I just scan and I'm logged in. It's perfect."
SQRL has been ready for years. Libraries are the killer app.
- ✅ Millions of users - 170M library cardholders in US alone
- ✅ Public institutions - Not profit-driven, privacy-focused
- ✅ Perfect use case - All the problems SQRL solves
- ✅ Trusted brands - Libraries are trusted community institutions
CHIMPY could be the deployment that proves SQRL at scale.
Libraries adopt SQRL → Pattern spreads:
- Libraries prove SQRL works (public institutions)
- Schools see success → Adopt for student IDs
- Credit unions see success → Adopt for banking
- Municipal services see success → Adopt for citizen portals
- Healthcare clinics see success → Adopt for patient portals
Libraries are the beachhead for public sector SQRL adoption.
Libraries + SQRL = Privacy advocates' dream:
- ✅ EFF (Electronic Frontier Foundation) supports libraries
- ✅ ALA (American Library Association) committed to patron privacy
- ✅ SQRL eliminates surveillance capitalism in public institutions
- ✅ "Libraries choose privacy over vendor lock-in" (great PR)
This is the narrative that wins hearts and minds.
CHIMPY is open source (MIT license):
chimpy-extract/ (ETL from Sierra to DuckDB)
└── MIT License
chimpy-kernel/ (Rust kernel, will be MIT)
├── SQRL authentication
├── Specification-first architecture
└── Reference implementation for libraries
Community:
├── Public specs (YAML, community-owned)
├── Conformance tests (auto-generated)
└── No vendor lock-in (libraries own everything)
Benefits for SQRL:
- ✅ Real production code (not just demo)
- ✅ Battle-tested in libraries (real users, real scale)
- ✅ Reference for other implementations
- ✅ Proof that SQRL works in vertical domains
Patron devices:
- iOS: SQRL app (existing)
- Android: SQRL app (existing)
- Desktop: Browser extension (SQRL support)
Library self-serve kiosks:
- Kiosk displays QR code
- Patron scans with phone
- Authenticated on kiosk
- Kiosk session ends when patron leaves
// Rust implementation of SQRL server in CHIMPY kernel
struct SqrlServer {
// Server stores patron's SQRL public key
patron_public_keys: HashMap<PatronId, SqrlPublicKey>,
}
impl SqrlServer {
fn authenticate(&self, request: SqrlAuthRequest) -> Result<Session> {
// 1. Verify SQRL signature
verify_signature(request.signature, request.public_key)?;
// 2. Check if public key exists (patron registered)
let patron_id = self.lookup_patron(request.public_key)?;
// 3. Generate session token
let session = Session::new(patron_id, expires_in_hours(2));
// 4. Audit log
audit_log(INFO, "Patron authenticated via SQRL", patron_id);
Ok(session)
}
fn register_new_patron(&self, sqrl_public_key: SqrlPublicKey) -> PatronId {
// Create patron account with SQRL public key
// No email, no password, no personal info
let patron = Patron {
id: generate_patron_id(),
sqrl_public_key,
created: now(),
// That's it. No other fields required.
};
db.insert(patron)
}
}Agent identity generation:
// AI agent gets SQRL identity
struct AiAgentIdentity {
agent_id: String,
sqrl_keypair: SqrlKeyPair, // Generated during agent registration
}
impl AiAgentIdentity {
fn sign_request(&self, operation: &str, params: &Value) -> Signature {
let message = format!("{}{}", operation, serde_json::to_string(params));
self.sqrl_keypair.sign(message)
}
fn verify_signature(request: &Request) -> Result<AgentId> {
// Kernel verifies agent signature
verify_sqrl_signature(
request.signature,
request.public_key,
request.message
)?;
// Return agent ID if signature valid
Ok(agent_id)
}
}Steve, we're building the authentication system libraries NEED.
And we want SQRL to be THE default. Not "an option". THE way.
Why?
- Libraries serve 170M+ cardholders - This is MASSIVE deployment potential
- Libraries are privacy-first - SQRL aligns with library values perfectly
- Passwords are a disaster - Libraries need SQRL's security model
- Public institutions matter - This is democracy's infrastructure
What we're asking:
- ✅ Feedback on CHIMPY's SQRL integration - Are we using SQRL correctly?
- ✅ Technical guidance - Best practices for SQRL server implementation
- ✅ Endorsement - "SQRL is perfect for libraries" (when we launch)
- ✅ Collaboration - We'll build the reference implementation, you get proof-of-concept at scale
What you get:
- ✅ Real-world deployment - Libraries using SQRL in production
- ✅ Open source reference - MIT licensed, battle-tested code
- ✅ Vertical domain proof - "Libraries chose SQRL" (others follow)
- ✅ Privacy advocacy win - Public institutions choosing privacy over surveillance
Let's make SQRL the authentication standard for public institutions.
Let's start with libraries.
This is THE WAY. 🚀
- SQRL: https://www.grc.com/sqrl/sqrl.htm
- CHIMPY: https://github.com/rayvoelker/chimpy-extract (ETL foundation)
- Specification-First Design: llore/031_specification-first-explained-simple.md
- CPC (AI Agents): llore/035_CPC-chimpy-protocol-agentic-clients.md
Ray Voelker
- GitHub: @rayvoelker
- Project: CHIMPY (Community Hub for Interoperable Modular Platform, Y-factor)
CHIMPY: Specification-first platform for library data sovereignty
SQRL: The authentication method for democracy's infrastructure 🔒📚
- ✅ No password to remember
- ✅ No email required
- ✅ No personal info collected
- ✅ 30-second setup
- ✅ Works across devices
- ✅ Different identity per library (privacy)
- ✅ Instant revocation if lost
- ✅ Zero password reset support burden
- ✅ No password database to secure/breach
- ✅ GDPR/CCPA compliance by default
- ✅ Reduced IT costs
- ✅ Improved patron satisfaction
- ✅ Competitive advantage (privacy-first)
- ✅ Secure TUI/SSH access
- ✅ No passwords to manage
- ✅ 2FA built in
- ✅ Audit trail of all access
- ✅ Time-limited certificates (SSH)
- ✅ Cryptographic identity
- ✅ No API keys to leak
- ✅ Signed requests (tamper-proof)
- ✅ Instant revocation
- ✅ Audit trail
- ✅ Public institutions choosing privacy
- ✅ Millions of users on SQRL
- ✅ Proof that password-free works
- ✅ Pattern for other domains (schools, credit unions, healthcare)
SQRL + CHIMPY = The future of authentication for public institutions.
TO THE MOON! 🚀💎🙌