Complete the description of the eosio crypto keys K1, R1 and Webauthn

[ghost]

No description provided.

[sanaraufx]

k1 = EcdsaSecp256k1VerificationKey2019
r1 = EcdsaSecp256r1VerificationKey2021
wa = FIDO2
WA = FIDO2HWKey
WA = FIDO2BioKey
WA = FIDO2Secp256R1Key
WA = FIDO2whateverothertypeofverificationsthatarepossible

Feedback about webauth:
The issue with wa is that most of the usages of it use hardware keys or biometric keys, etc. So, I don't think you'll be able to put into Json a way to verify, unless that particular fido2 authenticator is just going to utilize public/private keys in a pure software based solution (seems limiting).

We [EOSIO] do support hardware keys, in particular yubikey. The issue with hardware keys or biometric keys is that there is no "public key" per to use in something static like Json.

It will take a challenge from the outside to prove that it is what it's supposed to and then computes the keys internally and passes them back as part of the auth sequence.

[ghost]

1. what key type is r1, any documentation
2. how to determine the key type from the public key (that we read from the eosio chain)
3. some more information and documentation about the cryptography used

[ghost]

the "r1" is indeed the Secp256r1 curve. A bit more here https://crypto.stackexchange.com/questions/18965/is-secp256r1-more-secure-than-secp256k1
To implement, there is some extra work as we'd need to register it here https://w3c.github.io/did-spec-registries/#verification-method-types. alternatively, we could use JWKs but we would need to register it here https://w3c-ccg.github.io/lds-jws2020/#dfn-jsonwebkey2020

[ghost]

While Webauthn supports various keys, it seems like the eosio implementation only supports the R1 key. See here
EOSIO/eos#7421
EOSIO/fc#97
https://github.com/EOSIO/fc/blob/master/src/crypto/elliptic_webauthn.cpp#L236
@sanaraufx could you confirm?

Also to support this is that EC_KEY_new_by_curve_name(NID_X9_62_prime256v1) is used the same in both elliptic_webauthn.cpp and elliptic_r1.cpp
https://github.com/EOSIO/fc/blob/master/src/crypto/elliptic_webauthn.cpp#L233

This also may be useful for implementation
https://github.com/EOSIO/eosio-webauthn-example-app/blob/master/src/client/wasig.ts#L26

[ghost]

AFAIKT we can therefore use the key prefix in the eosjs implementation to determine the key type:

prefix	type
EOS (legacy)	EcdsaSecp256k1VerificationKey2019
PUB_K1_	EcdsaSecp256k1VerificationKey2019
PUB_R1_	EcdsaSecp256r1VerificationKey2021
PUB_WA_	EcdsaSecp256r1VerificationKey2021

[ghost]

Notes from call wit B1 with @spoonincode and @larryk85

K1 used for most keys
R1 use is very slim... maybe < 1%
WA not know to be used on public chains. protocol feature not activated on EOS mainnet

PUB_R1_ and PUB_K1_

• only difference in the K1 and R1 jwk object should be the curve property ("secp256k1" / "secp256r1")
• x and y can be read from the PublicKey object (from the elliptic package)
• kid property of the jwk is option, if we use it should be distinct, maybe use the eosio PUB_K1... string? maybe it takes up unnecessary space... https://datatracker.ietf.org/doc/html/rfc7517#section-4.5

PUBK_WA_ contains following data:

• public key using the R1 curve
• origin = used to ensure same origin as the creator sends the request (assumes the user is using a secure browser) which protects from phishing attacks
• some bits for user presence

PUBK_WA_

• requires a protocol feature to be activated
• they think eosjs does not support WA
• check the example webauthn app for reference of how to use

eosio does not define where the webauthn credential id is stored. this would typically be stored in the server. this is needed for webauthn protocol. no best practice was released by B1. suggest not to put this on-chain but they also didn't see a problem with it.

[ghost]

After discussing in the meeting today, we decided to go ahead and finished the first draft EOSIO DID spec with the K1 type only. We plan to make an implementation of R1 and WA in the resolver.

To close this issue, please finish the K1 key material description.

[ghost]

Resolved in PR #14