Mention full CTAP2 Android support in the README now that it is supported

[suut]

About 2 months ago there was an update to Android/Google Play services that adds support for CTAP2 using the native system UI.

The catch is that the SELECT APDU is done using extended-length which is usually not supported by the GlobalPlatform manager of JavaCards; to get around that the applet needs to be marked as default selected (for instance giving it the CardReset privilege) and it then will handle the "fake" SELECT like it would a real one thanks to these lines already present in the code:

        if (cla_ins == (short) 0x00A4 && p1_p2 == (short) 0x0400) {
            // Applet-select command, probably part of test shenanigans
            handleAppletSelect(apdu);
            return;
        }

I tested it on the Android 17 beta, but it should also work on the latest Android 16 release assuming Google Play Services are up to date.

It's worth mentioning that the app Authnkey (available on F-Droid or repackaged as FIDO Bridge - Authnkey on the Google Play Store) did allow to use the applet on Android for CTAP2/passkeys; but now the flow is native and consistent (but it still doesn't allow to manage credentials, then you still need an app).

[martinpaljak]

That seems like a weird move by the G company. Select with small payload but extended semantics? At the same time - like a "resolves only on ipv6" kind of push...

[suut]

Actually to properly support the extended-length select in addition to CardReset I think the code also needs some change to make sure no APDU other than SELECT is processed until a SELECT was received (otherwise the transient storage is not initialized by handleAppletSelect and bad things will probably happen); maybe with a transient boolean that is set to true when processing a SELECT ?

@martinpaljak Indeed it's weird, their rationale is that fully compliant CTAP2 authenticators must support the extended-length select so they use the extended-length select and they won't change it, even after being made aware that most (or all) card-form authenticators won't work with that

Java cards that don't support applet selection using extended encoding are not supported. If there are any regressions in the U2F flow, please open a bug and we're happy to help resolve the issue, but we will not be supporting non-compliant keys over CTAP2 so those keys should not be expected to support user verification.

https://issuetracker.google.com/issues/406833082