add webauthn public key and signature type#97
Conversation
b1bart
left a comment
There was a problem hiding this comment.
I cannot remember why we went for the "shim" pattern for R1 and K1, this does not use the same pattern and perhaps thats ok. At the very least, it maintains our external interfaces (serialization and variant) expectations so, we should be able to move to the "shim" pattern if we remember why we did it in the first place.
| ${CMAKE_CURRENT_SOURCE_DIR}/vendor/websocketpp | ||
| ) | ||
|
|
||
| # try and make this very clear that this json parser is intended only for webauthn parsing.. |
There was a problem hiding this comment.
This seems overly punitive. Is there a substantive reason that we would have to whitelist use of this json parser?
There was a problem hiding this comment.
Since JSON parsing is consensus I am concerned about the version of rapidjson being accidentally upgraded in the future and breaking that consensus. So, I tried to make it very clear this version of rapidjson is strictly for webauthn parsing: it's in a directory called webauthn_json and it can only be included from elliptic_webauthn.cpp.
Add webauthn key and signature support to fc. Public keys are comprised of three components: the compressed r1 public key, the webauthn user presence requirement, and the relying party ID (origin). Signatures are comprised of three components: the compressed signature, authenticator data blob from the webauthn authenticator, and client json string which is from the browser.
JSON parsing is required to extract the webauthn challenge, origin, and signature type from the client json. RapidJSON is brought in as a submodule strictly for use with webauthn json parsing.
A fair number of changes are added not strictly for webauthn support in fc but also to facilitate usage of the webauthn key type in eosio where it will be gated via a protocol feature and special handling for chainbase storage of webauthn keys due to the variable length nature of them.
It's important to remember that this is consensus changing so it should be merged to fc's master only on the cusp of the corresponding PR in eos that gates webauthn support via a protocol feature.