ATProto with passkeys and embedded wallets

[Kzoeps]

This is a prototype to try and integrate passkey authentication and using that to create embedded wallets and to use it.

Attached is a picture with the basic flow of how this goes about:

had a few issues with react 19 and privy hooks so i handled the wallet creation on the client side manually after registering with passkey.

also sometimes there are issues with registering the passkey and creating the wallet. as in a passkey is created but wallet isnt generated and stored. Delete the passkey and try again and it works second time around.

[Kzoeps]

here is a loom video demonstrating it

https://www.loom.com/share/1d38df4da251445385ae5c3bf6bbdb03?sid=0605db89-97a3-4491-9dba-6df882b98165

github repo link: https://github.com/kzoeps/did-wallet-connection
the page concerned with this is the root page.

test url https://did-wallet-connection.vercel.app/

[aspiers]

Thanks @Kzoeps! Please could you share the GitHub repo link, as the above link is wrong?

[aspiers]

Would it be possible to reduce the OAuth scope so that CRUD is only possible on the org.hypercerts namespace within ATProto? The current scope is very broad and makes me feel a bit uncomfortable giving it write access to my entire social profile:

[Kzoeps]

yess been thinking about this as well. ill update the scope for this and edited the repo link. and here as well

https://github.com/kzoeps/did-wallet-connection

[s-adamantine]

Nice! Would it make sense to add the wallet to the "alsoKnownAs" section of the user's DID? Since the wallet is not necessarily hypercerts specific

[aspiers]

AFAIK a wallet allowing non-interactive login without the user's permission would be a major security issue, so I'd be very surprised if this was possible. But yeah worth checking, thanks.

[bitbeckers]

AFAIK a wallet allowing non-interactive login without the user's permission would be a major security issue, so I'd be very surprised if this was possible. But yeah worth checking, thanks.

@aspiers in all fairness, this is somewhat what you can do with these embedded wallet providers. In the PoC for logging in with Bluesky -> Alchemy SA -> Supabase, the Alchemy step is handled in the backend based on the Bluesky login.

The nuance here is that the login is interactive on the ATProto step, non-interactive for the wallet. Just wanted to highlight this

[aspiers]

Sure, the point is that the user is required to give permission at least once per login flow, and also per signature unless there is some kind of prior permission for the wallet to act on the user's behalf (e.g. via session key and smart account policy). When bootstrapping a connection between 2 different identities (e.g. Bluesky and EVM account) there is no such prior permission given by the user.

[bitbeckers]

When bootstrapping a connection between 2 different identities (e.g. Bluesky and EVM account) there is no such prior permission given by the user.

This is the point of the JWT based flows right? How I understand your point, I agree with the security issue but this is kinda what embedded wallets enable. The next barrier after login is executing transactions and I think this is where approvals are required again (but iirc you can sign a blanket approval with Privy)

[aspiers]

This is the point of the JWT based flows right?

Sorry, I'm not sure I totally follow which point you are referring to here? Probably I didn't explain myself clearly enough (I wrote it late at night and was falling asleep!). If you mean a typical OAuth / OIDC flow, then the user is always initially asked for permission to use their account with the OAuth provider. But anyway I wasn't talking about the OAuth side of the bootstrapping - instead I was referring to the process of generating a signed SIWE message which can be stored in the PDS to prove ownership of that onchain account.

Reading your previous message again:

The nuance here is that the login is interactive on the ATProto step, non-interactive for the wallet.

I guess the non-interactive part here refers to creation of the Alchemy wallet? But again, that's not the part I thought we were focusing on in this particular sub-thread. At least, I was focusing on the SIWE signature generation, and I wouldn't expect that Privy or Alchemy or any wallet service would allow generating this non-interactively immediately after a fresh wallet has been created.

How I understand your point, I agree with the security issue but this is kinda what embedded wallets enable.

Wallets, embedded or otherwise, don't (and shouldn't!) generate any signatures without the user's explicit permission, either just beforehand, or in advance via some policy mechanism. That's really the core point I was making, specifically in response to this:

@Kzoeps commented on September 16, 2025 8:55 AM:

ill try and see if it would be possible to sign the message yusing the embedded wallet during the creation with passkey without any user interaction (idk if thats possible but will look into it)

In this context, I was saying a) I suspect it's not possible, and b) explaining why I suspect this - i.e. because wallet security models require asking the user for permission for every action they do on behalf of the user, at some point before the action takes place. That principle means it seems unlikely to me we'll be able to achieve a SIWE flow immediately after wallet creation without that wallet explicitly asking the user to manually authorise the SIWE signature. I've trawled through the Privy docs and can't (yet) see any evidence to the contrary. For example, signing via eth_signTypedData_v4 requires a privy-authorization-signature header, which is documented here:

https://docs.privy.io/api-reference/wallets/ethereum/eth-signtypeddata-v4#param-privy-authorization-signature

That said, maybe you guys have more up to date knowledge of Privy than I do. Also I find the Privy docs a bit of a maze (especially all the stuff around users / owners / signers / authorization keys), so it's entirely possible I've missed something.

The next barrier after login is executing transactions and I think this is where approvals are required again (but iirc you can sign a blanket approval with Privy)

Right - a user can grant a wallet permission in advance for it to do all kinds of things on behalf of the user. And of course smart accounts can also use session keys to accomplish this. However it's worth noting that an onchain smart account can not generate signatures for messages such as SIWE or similar. I don't believe EIP-1271 can help with that either. (This is one of the reasons that I'm sceptical that smart accounts by themselves can act as holistic solution for authorisation, at least not yet.)

BTW I'm pretty sure we're not disagreeing on anything at all here. Instead, it feels more like the kind of deep technical discussion which is 100x harder over async messaging than being able to scribble a diagram or two together in person 😜 I'd love to help draw some sequence diagrams on all of this because I think it makes remote collaboration way easier!