maneuler / vaultPasskeys and credential providers
Proposal, not an available feature. No network permission or new data collection is enabled. These RFCs are locally prepared; remote review/merge awaits the owner repository.
Current architecture
WebAuthn in a normal website requests a credential from an authenticator; it does not make that page a system-wide passkey provider. The current popup extension and Capacitor app have no credential-provider integration.
Design under review
Prototype discoverable credentials behind a disabled development feature, with RP ID, user handle, algorithm, credential ID and private material protected inside KDBX custom fields. WebAuthn use for a Vault-origin login is separate from storing other websites’ passkeys. Implement a native OS credential provider and a browser-approved mediation path before advertising a password-manager passkey feature.
Milestones
- M1: documented credential schema and external KDBX preservation vectors; no enrollment UI in production
- M2: Chromium/native provider proof with origin/RP binding, user verification, cancellation and negative tests
- M3: physical iOS/Android enrollment and authentication against independent relying parties; security review before rollout
Required acceptance tests
- Wrong RP ID and origin cannot sign
- User cancellation and lock clear pending requests
- Unsupported algorithms fail without corrupting stored credentials
Limits
Passkey import/export between providers is not assumed. OS entitlements, supported browser APIs, provider policy and independent review are gates.
Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.
Primary references: www.w3.org · developer.chrome.com · developer.apple.com