I’m working on implementing a non-custodial wallet using WebAuthn (passkeys/biometric authentication). However, I’ve hit a fundamental compatibility issue:
Current Problem:
WebAuthn uses P-256 (secp256r1) for signatures
Clarity only supports secp256k1 verification
This forces complex workarounds that reduce security
Current Workarounds:
Store an encrypted secp256k1 key in browser storage
Use WebAuthn to decrypt it
Sign with secp256k1
Verify with secp256k1-verify
This adds unnecessary complexity and attack surfaces compared to using WebAuthn’s secure enclave directly.
Proposed Solution:
Add P-256 signature verification to Clarity, enabling:
WebAuthn key stays in secure enclave
Public key stored in contract
Direct signing from secure enclave
Contract verifies P-256 signature
Questions:
Is adding P-256 verification to Clarity feasible?
If yes, could someone point me to relevant code (like the secp256k1 implementation) that I could learn from to potentially contribute this feature?
What would be the process for proposing/implementing such an addition?
This would enable truly secure, non-custodial wallets using native device security without compromising the security model with additional key storage.
Let me add that important use case to the post:
Real World Impact & Mass Adoption:
The ability to use WebAuthn natively would enable a powerful user experience for mainstream adoption:
User buys sBTC/asset with credit card
Assets are sent to a smart contract wallet
User can access/control their assets using just their device’s biometrics (Face ID/Touch ID)
No seed phrases to manage
No complex key management
Security backed by device hardware
This creates a familiar authentication flow that mainstream users already trust (similar to Apple Pay or banking apps), while maintaining the non-custodial nature of crypto. It bridges the UX gap between traditional finance and web3 without compromising on decentralization.
This could be a significant step toward making Stacks more accessible to mainstream users who are comfortable with biometric authentication but hesitant about seed phrase management.
The deep technical bits are beyond me, but I love the proposal’s goal of making Stacks more real-world-friendly. I wonder if @marvin.id has thought about this given his work on Ryder and could offer some comments here
Thank you @cuevasm - completely agree it would be great to get @marvin.id’s insights given his experience with Ryder!
To clarify - Nicolas Bacca’s project smoo.th on Ethereum L2s is actually implementing direct passkey integration without workarounds, as those chains support the native secure enclave signatures. While there are some edge case vulnerabilities (particularly during device synchronization as shown in his talk: https://www.youtube.com/watch?v=TEjNSr8jjUI), the massive UX improvement makes it a worthwhile tradeoff for onboarding when risks are properly disclosed.
From Faktory’s perspective, even the current workaround implementation (though less secure due to potential browser key interception) could serve as a valuable experiment for limited-value use cases - like sending gift cards to friends.
The key question remains whether building native Clarity support for the passkey algorithm is feasible, and @marvin.id’s perspective on this would be incredibly valuable.
We’re working with passkey in the manner you mention here at Boom. Keep in mind that passkeys are device dependent, so you still would want/need a back-end ID that users can use across devices for the same account.
From this perspective, the current Stacks wallet is actually useful.
At Ryder, we use a custom secure element and we decided to base our device security mechanisms on secp256k1 instead of secp256r1 (or other) for that exact reason.
Passkeys-compatible Stacks transforms our existing devices into potential hot wallets, and I’m curious if other Stacks builders will notice this potential.
