Jakob Heher

For our use case, we are exclusively concerned with `excludeCredentials`, yes. We are looking to use WebAuthn credentials on appropriately-certified authenticators as a single login factor – the "passkey setup"....

In particular, the `getCredentialIdsForUserHandle` approach would not allow use cases where the "internal identifier" should not be exposed to the user; it still forces the credential repository to solely operate...

Adding this kind of field to `StartRegistrationOptions` would also solve our specific use case (by allowing us to circumvent the `CredentialRepository` entirely,) yes. It still _feels_ like it'd lose flexibility...

Hmm, yes, we could potentially make that work. Even though I understand the library guarantees you describe, it still doesn't feel like a clean solution; it feels like something that'd...

Ah, I missed the `excludeCredentials` use case. Hm, this presents somewhat of a conundrum. If I set `username` to the internal (personal-data) identifier, this allows me to implement `getCredentialIdsForUsername`, but...

If you don't mind me requesting further input, since I'm really trying to avoid "fighting the library" here: Assume I have some opaque server-generated metadata that is attached to each...

`Optional getExtraData(Class)` sounds like a potential solution for the type safety issue, mapping an internal ClassCastException to an empty Optional.

Just as a heads-up, the technical demonstrator project on our end is wrapped up, so I may not find much time to be active in these issues (though they continue...

Thanks for your quick response! The client-side `getPublicKey()` method does not seem like a workable solution for us, since we use authenticator attestation. Since only the COSE public key is...

This is also causing significant annoyance for our QA department. Our build script produces a pre-packaged platform-native archive (.zip, .tar.gz, .dmg), which is then re-zipped by Github when stored as...