byoi
BYOI — Bring Your Own Identity
A user-owned, passwordless authentication system built on decentralized identifiers and device-native cryptography.
BYOI explores a simple but under-examined idea:
Identity should be owned by the user, not issued or controlled by the application.
Instead of passwords, OAuth brokers, or centralized identity providers, BYOI enables authentication using self-owned cryptographic identity, verified via Decentralized Identifiers (DIDs) and WebAuthn-backed device authentication.
Problem statement
Most authentication systems fail not because of poor implementation, but because of structural assumptions:
- Passwords require centralized secret storage and constant defense
- OAuth centralizes trust in a small number of identity providers
- “Login with X” implicitly transfers identity ownership to X
- Applications inherit compliance, breach surface, and vendor lock-in
- Users lose portability and privacy by default
These are not bugs. They are properties of centralized identity models.
BYOI was built to explore an alternative boundary:
What if identity were cryptographically user-owned, portable by design, and verifiable without delegating trust to a central authority — while remaining usable in real systems?
Design goals
BYOI optimizes for the following constraints:
- User ownership of identity material
- No shared secrets between users and applications
- Local authentication, bound to the user’s device
- Minimal trust surface for applications
- Interoperability with existing web standards
Non-goals (explicitly):
- Mass consumer onboarding optimization
- Social-login convenience
- Identity recovery without user custody trade-offs
Core model
BYOI cleanly separates identity ownership from authentication verification.
Ownership
- Identity is represented by a DID
- Private keys are generated and stored locally
- No application or server ever holds user secrets
Authentication
- User presence and consent are enforced via WebAuthn
- Authentication occurs on the user’s device
- Applications verify cryptographic proof, not credentials
In short:
Applications verify signatures. Users retain identity control.
System architecture
1. Browser Extension — Identity Agent
The browser extension acts as a user-controlled identity agent, not a password manager.
Responsibilities:
- Create and manage ION-based DIDs
- Generate and store private keys locally
- Bind authentication to device biometrics via WebAuthn
- Sign authentication challenges
- Isolate private keys from web contexts
Trust boundary:
- The extension is the only trusted component
- All authority originates from the user’s device
Chrome Web Store Distribution: https://chromewebstore.google.com/detail/bring-your-own-identity-b/eaoknlfgonfekahpfdpmafpipfdnejji
2. SDK — Application Verification Layer
The SDK exists to keep applications out of identity complexity.
Responsibilities:
- Initiate authentication challenges
- Communicate with the user’s identity agent
- Resolve DIDs and verify cryptographic proofs
- Abstract WebAuthn and DID resolution flows
- Integrate with existing backend systems
Applications never:
- Store passwords
- Store private keys
- Handle biometric data
They only verify signatures against a DID.
NPM Package Distribution: https://www.npmjs.com/package/byoi
Trust & threat model
| Aspect | Traditional Auth | BYOI |
|---|---|---|
| Identity authority | Central provider | User |
| Secret storage | Server-side | Device-local |
| Authentication | Knowledge-based | Possession + biometrics |
| Breach impact | High | Limited |
| Portability | Low | Native |
| Vendor lock-in | Common | Avoided |
BYOI intentionally minimizes server trust while maintaining verifiability.
Why decentralization is used (and where it is not)
Decentralization is applied only where trust boundaries demand it.
- Decentralized: Identity (DIDs)
- Local: Authentication (WebAuthn)
- Centralized: UX, application logic, developer tooling
This avoids the common failure mode of decentralizing everything and shipping nothing usable.
Intended use cases
BYOI is suitable when:
- Identity ownership matters
- Platforms should not become identity gatekeepers
- Privacy and long-term portability are requirements
- Passwords are an unacceptable risk
Examples:
- Privacy-first platforms
- Federated or decentralized systems
- Fintech, healthcare, legal infrastructure
- Communities prioritizing digital sovereignty
Not optimized for:
- High-churn consumer apps
- Social-login-centric UX
- Environments where identity custody is unimportant
These trade-offs are deliberate.
Implementation stack
- DID:ION — decentralized identifiers anchored on Bitcoin
- WebAuthn — W3C standard for secure, device-bound authentication
- TypeScript
- Web Crypto API
- IndexedDB
- Browser Extensions API
All components rely on established, auditable web standards.
Repository structure
/extension— identity agent architecture, flows, and security decisions/sdk— integration API, verification logic, and developer abstractions
Detailed documentation lives alongside the code.
Project motivation
BYOI is not a product pitch.
It is an engineering exploration of what modern web identity could look like if we stop assuming centralized ownership is inevitable.
If it leads to better systems, better abstractions, or better conversations — it has succeeded.
Contributions
This project welcomes contributors interested in:
- Identity architecture
- Trust boundaries
- Protocol design
- Security-first abstractions
Discussion and critique are encouraged.