Use cases for ecdsa p256 / prime256r1 / secp256r1 / es256

[vale marlin]

Hi all,

A while ago there was an ask to add secp256r1 support to Soroban.
https://github.com/stellar/rs-soroban-env/issues/807

I'm exploring and experimenting with this some more.

If you have a use case for using this crypto, please post about it in this thread, and here:
https://github.com/stellar/stellar-protocol/discussions/1435#discussioncomment-8341261

[dapper ember]

https://www.youtube.com/watch?v=XELhxgMQHNk

[silver finch]

I'm intrigued by the possibility of using my face to sign transactions.

[floral path]

I'm all thumbs

[manic heron]

I am wondering something. Compared to a Yubikey, is the biometric information then less secure? In the sense that as opposed to a Yubikey, we don't generate new faces or fingers 😅
Also for the fingers especially, I would be concern that someone could fake my print to sign transactions. This is not just a spy movies thing anymore. Even FaceID could be tricked with high quality masks. Not accessible to everyone, but the tech is definitely there to fake/steal all that.

[hollow pollen]

They will need both your face/finger and also your device. The keys are not generated from your face/finger (similar to how fingerprint/faceid works)

[manic heron]

Ah ok 👍

[dapper ember]

Especially with AI now. Very legitimate concern imo. More for face than fingerprint though. Still, they’d need your device.

[manic heron]

If it's tight to a physical device and you cannot do without it then I guess it's good

[hollow pollen]

Regarding the feature, I still need to check the repo (will do it tonight) but one question... If I understand correctly this is only the authorization part using a custom account in a contract, this means it also needs a regular stellar account for paying the fee and sending the transaction correct?

[dapper ember]

I believe that’s correct but @vale marlin could confirm

[errant ether]

With the ability to "securely" sign txs, essentially this turns every compatible device into a wallet, without any user friction (seed phrases, storing secret keys, etc.).
I wonder if anyone is thiking on using a threshold scheme with this.

[errant ether]

I'm sure everyone has read about this: https://edition.cnn.com/2024/02/04/asia/deepfake-cfo-scam-hong-kong-intl-hnk/index.html

[civic escarp]

This is for me is a great idea to integrate in to the soroabn platform Because he really wanna make it easy for users to sign transactions, which is why we developed this for traditional Stellar with our zig3 Wallet on the front end this would just be absolutely amazing using webauthn At contract level. I just think we need to talk about it more.

I feel like if you’re worried about your wallet being hacked via AI, surely your wallet is just a wallet it should hold small amounts of value you’re not gonna hold your life savings in there are you?

This concept reduces cognitive complexity And allows for a seamless interaction When I think about how many times I use biometrics I can’t actually remember a time when I’m inputting the password other than having to sign up for something surely this is the standard now?

[vale marlin]

This is corect. Face/finger is depending on your device unlocking it like a pin code or similar. The key is not based on those things. It's just gaining access to the key that's stored on the device.

If you're using an iOS device the key will likely be stored in iCloud Keychain if you're using that, or maybe in the Android backups. Not sure where it gets stored on Windows.

In browsers the key is linked to a domain. So unclear to me how to use it in a way that it is unlinked from a domain.

Some password managers support webauthn now, and can store the key too instead. 1password I think, but I haven't tested with it.

[manic heron]

This is so cool 🙂

[vale marlin]

Yubikeys that are relatively new (last couple years) or other hardware devices can be where the key is stored too, webauthn is just a common API for accessing all these things.

[dapper ember]

I have. It works
At least on desktop

[civic escarp]

Quick question to consider that sprung to mind, will this work on a web3 domain. Will it work in a brave browser?

[vale marlin]

It does work in Chromium browsers. I haven't teste Brave specifically but I imagine it should since Chrome does.

The domain issue is real, and I'm interested in whether extensions can use webauthn and what domain gets used for the extension, and also on phones how native applications can use it.

[dapper ember]

Time to flex my Tauri skills
https://beta.tauri.app/blog/tauri-2-0-0-beta/

[civic escarp]

I was thinking may be using a web3 domain to host addresses from other chains and using the soroban smart contract platform as a bridge to other chains. By doing this your only having to use the domain name as the address for all chains not sure how possible this is, but the idea has been in my head for some time now

[hollow pollen]

From Extensions the support is not that great, but still possible by intercepting the native flow (minus firefox, it has a bug since 2 years ago and it hasn't been fixed)... I don't know about mobile but I can test it

[civic escarp]

Using webauthn for this would be great

[dapper ember]

@hollow pollen the hero we need, but don't deserve

[potent pagoda]

This is awesome. I just bought 2 YubiKeys 2 weeks ago, the BioMetric ones for another project. I'm all in. Let me know how we can help.

[prisma willow]

Is this the way to intercept as a browser extension? (see "stop gap solution" in original post) https://github.com/w3c/webauthn/issues/1976

[hollow pollen]

Yeah that's a way, basically what extensions do is they modify the navigator object of the page so if webauthn is used the extension handles it instead of the regular browser flow. This is how Bitwarden handles it: https://github.com/bitwarden/clients/blob/1f8e6ea6f8a736a8a766e5e0643c7106adfa8433/apps/browser/src/vault/fido2/content/page-script.ts#L59C32-L59C56

That being said, that's not a perfect solution cuz if two extensions are installed and they both do the same then it's a race issue

[dreamy totem]

wrt webauthn is there a need to also support CBOR? I am not familiar with how all this works and fits together

[prisma willow]

@vale marlin's implementation didnt seem to need CBOR but I do see gh issues in the webauthn repo

[dreamy totem]

yeah I just don't know if there are cases where you need to crack open what came straight from the authenticator

[hollow pollen]

So I'm playing a little bit with this and one concern comes to my mind: Since this is an abstraction of an account and at minimun there are two signatures involved (the stellar account paying the fee and the contract account) it means that all stellar/soroban apps/websites will need to be updated because all of them use the same account that is paying the fee as the one the user will use to sign the transaction (talking about dapps, not wallet)

Is this something that could be updated in the future? Like allowing certain types of contracts to pay for the fee and be the source of a tx? (I think I already know the answer to this but I have hopes 😂)

[errant ether]

(that sounds like a relayer 😉 like I mentioned that day during leigh's presentation)

[vale marlin]

Yup a relayer or a bundler could pay for the fee, so could be a feature of the wallet. There already are wallets that pay fees for folks using fee bump transactions.

[hollow pollen]

yeah I understand the idea of a centralized service paying for the fees, but that's not my concern since that's something many are already doing, it's more about that it's not going to be compatible with any already created stellar apps because many (for not saying all of them) are expecting the source account to be the same account the user is using and in this case the public key is actually a contract id which if I'm not wrong it can't be a source account on a transaction

[errant ether]

I think this is such a good feature that backwards compatibility might need to be broken. And I don't say that lightly, as from all this time it is quite obvious how Stellar always plays more on the conservative side and would rather delay (by years) to do something great (yes, I mean Soroban).
However, if we are breaking ground to allow innovation to come in, well, via early adopters and building edge features, then probably they might not be aligned with what's in here.
I guess the trick is finding middle ground?

(or find a path to upgrade/migrate) 🙂

[hollow pollen]

I'm not saying we need to delay this because of that "breaking change", hence why I asked if there was the possibility to allow contracts to be the source account of transactions in the future. Because the issue I see now is that those wanting to use/offer this to their users will be left out without actually being able to do anything on Soroban because nothing will be compatible (not even exchanges will be compatible and they are the ones that take years to even support something AKA muxed accounts).

This means that dapps creators and exchanges could decide to not support this if there isn't enough demand (a chicken and egg dilemma)

[errant ether]

"possibility to allow contracts to be the source account of transactions in the future" 👍 👍 (aka fee payer)
"they are the ones that take years to even support something" .. yeah, that's more because of Finance/Legal than the tech 🤣
"to not support this if there isn't enough demand" ... I actually see this as more of a platform (meaning Stellar/Soroban) service/feature down the road... and this would be more of a "how difficult" it is to implement (or integrate) for 3rd parties.

... por cierto, no queria sonar negativo mi pana! 🍻 🍻

[vale marlin]

This is good call out, and I've added it to my task list to go deeper on.

I was under the impression that CBOR isn't needed because it's only used for attestation messages and extensions. Of which I don't think the contract itself needs to parse. The contract just needs to parse the resulting messages for verifying the signature.

The prototype doesn't decode CBOR because the client data JSON is well JSON formatted.

If all a developer wants a webauthn contract to do is verify a signature by a private key, then the contract will only need to:

• Verify that the signature of sha256(authenticator data + sha256(client data json)) is valid.
• Verify that the client data json contains the Soroban auth hash as the challenge.

However, the authenticator data may need decoding depending on what a contract wants to do. And the authenticator data is a custom format, not CBOR. https://www.w3.org/TR/webauthn-2/#sctn-authenticator-data

The authenticator data contains a signature counter, which a contract might want to check never goes backwards. The prototype doesn't include this check, but I can add it, since more security is preferrable. Parsing the authenticator data is rather small effort though, nothing too complex there.

The authenticator data can contain extension data at the tail section, so if a contract wanted to parse the extension data then yeah it'd be CBOR.