ctap | Test Anything Protocol for C

I need two dependencies from the same organization, but it seems the link to their source is broken.

First: https://mvnrepository.com/artifact/org.moxieapps.gwt/uploader

Second: https://mvnrepository.com/artifact/org.moxieapps.gwt/highcharts

There are many sources that say FIDO2/CTAP2 is backward compatible with U2F:

...all previously certified FIDO U2F Security Keys and YubiKeys will continue to work as a second-factor authentication login experience with web browsers and online services supporting WebAuthn. - Yubico

But after looking at the specifications, I'm having trouble seeing how that actually works in practice. Specifically, it seems like there is a mismatch between FIDO2's relying party identifier and U2F's application identity.

In U2F, the application identity is a URL, like https://example.com. SHA-256 of the application identity is called the application parameter. The application parameter is what is actually sent to the authenticator during registration and authentication.

In FIDO2, the equivalent seems to be the relying party identifier, which is defined to be a domain name, like example.com.

The relying party identifier and the application identity serve the same purpose in both FIDO2/CTAP2 and U2F. However, CTAP2 authenticators get the relying party identifier directly as an UTF8 string, whereas U2F authenticators only get a SHA-256 hash of the application identity (the application parameter).

The FIDO documentation for CTAP describes how CTAP2 maps onto CTAP1/U2F. In it, they simply treat the relying party identifier directly as the application identity:

Let rpIdHash be a byte array of size 32 initialized with SHA-256 hash of rp.id parameter as CTAP1/U2F application parameter (32 bytes)

This seems inconsistent. Let's say I were example.com, and I adopted U2F second-factor authentication early on. My application id would be https://example.com, so my original U2F application parameter would be SHA256("https://example.com"):