Allow validators to send challenges for webauthn

[RockwellShah]

Context: we've seen a lot of interesting work lately around using webauthn to create crypto wallets (and embedded accounts).

One of the things holding back adoption of these approaches is that centralized servers still have to send challenges for verification. If we could bake that ability into the validators we could open new onboarding methods that would be secure, decentralized, easy to use, and eliminate a lot of the friction we see with current web3 onboarding.

[gatesyp]

This can be done using a precompile approach, EIP here:
https://eips.ethereum.org/EIPS/eip-7212

Active discussion thread w/ reference implementations here:
https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789/57

Overall, very useful for enabling native account abstraction usecases on the C Chain (and any subnet using subnet-evm)

[patrick-ogrady]

I had no idea you guys ended up writing a blog about using passkeys (and their associated challenges). Linked to it here: https://x.com/_patrickogrady/status/1715094121776631995?s=20

[patrick-ogrady]

Nuance that ended up being very important to handle IMO is restricting malleability (which 7212 ended up not restricting): https://github.com/ava-labs/hypersdk/blob/9c184578d8d1536964abe34055754e15bde644fe/crypto/secp256r1/secp256r1.go#L43-L74

Even if devices don't create valid signatures, they can easily be modified to be in the lower half of the curve order (just like what was done on BIP-62).

[patrick-ogrady]

Does the "origin" in these requests have to return something specific or can it somehow be mocked?

Wondering if it would be possible for people to agree on some "null" origin that could be used across all applications? Maybe that is just wishful thinking and the browser forces you to use the origin of the site you are on...