Webauthn RP ID matching too strict

[jafri]

As per W3C RP ID specs at https://w3c.github.io/webauthn/#relying-party-identifier

"Given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: login.example.com (default) and example.com, but not m.login.example.com and not com."

However, fc does a rpIdHash === sha(clientDataJSON.origin) match which is too strict and does not cover the case where the origin may be login.example.com while the rp id is example.com:

fc/src/crypto/elliptic_webauthn.cpp

Line 213 in ff56d25

FC_ASSERT(memcmp(c.auth_data.data(), fc::sha256::hash(rpid).data(), sizeof(fc::sha256)) == 0, "webauthn rpid hash doesn't match origin");

[tbfleming]

It would be nice to relax that. It will take a hard fork to do so.

[jafri]

A hard fork is fine, best to do it now before more usage of webauthn in EOSIO

[DenisCarriere]

When mixing subdomains, push transaction on Nodeos causes the following error:

{
  "code": 500,
  "message": "Internal Service Error",
  "error": {
    "code": 10,
    "name": "assert_exception",
    "what": "Assert Exception",
    "details": [
      {
        "message": "memcmp(c.auth_data.data(), fc::sha256::hash(rpid).data(), sizeof(fc::sha256)) == 0: webauthn rpid hash doesn't match origin",
        "file": "elliptic_webauthn.cpp",
        "line_number": 213,
        "method": "public_key"
      },
      {
        "message": "",
        "file": "transaction.cpp",
        "line_number": 78,
        "method": "get_signature_keys"
      }
    ]
  }
}

[smlu]

fc/src/crypto/elliptic_webauthn.cpp

Lines 200 to 202 in ff56d25

	char required_origin_scheme[] = "https://";
	size_t https_len = strlen(required_origin_scheme);
	FC_ASSERT(handler.found_origin.compare(0, https_len, required_origin_scheme) == 0, "webauthn origin must begin with https://");

Also relaxing restriction for localhost to require security context would be great. This would allow local apps to run in browser without the need for custom certificate and TLS connection.

[spoonincode]

I believe this was deliberate. EOSIO is modeled such that a single key is recovered from a signature, and a key must exactly match a key that is in an authority. Recovering multiple keys from a native signature (such a recovering a bunch of PUB_WA keys with all the valid rpids), or allowing a recovered key to "fuzzy match" a key in an authority, were both considered too much at odds with existing EOSIO design.