Authentication, note transmission, passkeys, key exchange and the likes

[Janmajayamall]

Ideally we should support metamask, or any other existing wallet, and passkeys as methods of authentication. The user should be able to receive/send transactions once they have authenticated via one of the methods.

Auth via metamask

Metamask support deterministic ECDSA signatures. That is, two signatures produced across two different timestamps but on same message using the same secret will be the same. The hash of the signature (with the decorator) becomes the seed. The seed can be used to derive multiple secrets, especially the spend key.

I'm unsure which other wallets support deterministic ECDSA signature.

Auth via Passkeys

Passkey has an optional PRF support which allows deterministic seed derivation across two different timestamps. Several applications use the PRF to derive symmetric encryption keys, for instance. Following are links to further content:

• https://1password.com/blog/encrypt-data-saved-passkeys
• https://github.com/FiloSottile/typage
• https://levischuck.com/blog/2023-02-prf-webauthn
• https://words.filippo.io/passkey-encryption/
• https://confer.to/blog/2025/12/passkey-encryption/

Encrypted note transmission

Once we've a secret seed derived securely either from metamask or passkey, the seed can be used to derive different key types: keys for note transmission over network, private_identifier, spend_key.

Note that in the protocol, private_identifier and spend_key are distinct, they necessarily need not to be linked to each other. Nullifier key, public identifier, and the address are derived from the private_identifier. The protocol does not care about note transmission, so viewing keys are not take care of (they are taken care of the application level).

[Janmajayamall]

Claiming funds

TODO: explain how bank can facilitate receiving payment on user's behalf.

[Janmajayamall]

The client needs to do two things:

• construct transactions
• sign them with spend_auth

We'll split the codebase for the client into two parts: ts, rust

ts should implement:

• deterministic key derivation (i.e. seed in our context) using PRF extension of webauthn, metamask signatures
• derivation of private_identifier, spend_auth from seed
• tx_creation via rust fn call
• signature on tx_hash via rust fn call
• send tx details, spend_auth signature to subpool config server over an API call.

[Janmajayamall]

link to ts passkey demo https://github.com/oblique-security/webauthn-prf-demo

[Janmajayamall]

Safe and tessera

In certain applications it'll be nice to use safe as the public account counterpart to tessera account. For example, in Ethena the safe contract receives redeemed awards (since redeem needs to be public) on spend. Then how can one transfer these awards into their tessera account? I believe the same flow as deposit will follow here. Moreover, the safe account can be modified to allow batch transfers.