`ctap2_discoverable_creds`-example fails for mooltipass

I did some digging in the meantime and it seems that the mooltipass is not returning the name field, even though it is set when the credential is created (and is stored as I can see it on the screen). There does seem to be a possibility in the spec to not send the name field back when the user is not verified, but I consider that a discussion to be had on the mooltipass side whether this applies or not (I'm assuming it doesn't really apply and the mooltipass should send the name field)

Originally posted by @VincentVanlaer in https://github.com/mozilla/authenticator-rs/issues/237#issuecomment-1488103175

Thanks @VincentVanlaer!

Also note: It is only our example-binary that fails here, which just stupidly unwrap()s on the User name. In Firefox, there is a fallback, so we shouldn't error out there.

But especially for discoverable credentials, it would be very helpful for the mooltipass to return the username, otherwise it's hard for the user to decide as which account he wants to log in (e.g. if you have 2 different accounts on the same webpage). Or does the account selection happen in the device-UI itself?

Start with the ctap2_discoverable_creds example and inspect how it handles a missing user name. Compare that behavior with Firefox’s fallback in the linked WebAuthnController.cpp reference; done means the example no longer fails when the authenticator omits the name field.