Hi, We have a usecase where our website uses safari and has adopted webAuthN, say enrollment has happened in web using Safari and thus, passkeys for that user account User A in Website A has been created. We have an App for the same website, so, when we enable autofill and adopt passkeys for authentication, Since the passkeys are icloud keychain sync'ed, Either autofill or through Modal, we would receive all Passkeys created in website A as domain is same in App entitlements as well. For passkeys created through App, as recommended in webAuthN approach, we store the cred Id/username so as to fetch the challenge using that populate the same in AutoFill but for Passkeys created in web, though the success delegate method has ASAuthorizationPlatformPublicKeyCredentialAssertion object, it does not have challenge passed to it at first place as most passwordless providers require User Id as an attribute to generate challenge. We had SecrequestSharedWebCredential which could retrieve us credentials and thus, with the user name for this scenario but has been deprecated from iOS14. is there any alternate way to fetch atleast the user Id for the domain from iCloud Keychain?
Retrieving the userID to create the challenge was recommended in the past with CTAP1/U2F because knowing the userID before requesting an assertion was required for it to work. All U2F credentials are a type of credential known as "non-resident" or "non-discoverable", meaning they're not actually stored on the authenticator and instead derived from the credentialID used in the allow list. This means you always had to know who the user was before issuing a challenge, making these credentials mostly useful as a second factor.
With passkeys and modern FIDO2, this is no longer true. Passkeys are always "discoverable" credentials, meaning you don't need to use allow lists or identify the user before sign-in at all. With no saved state or prior knowledge, you can issue an assertion request with a random challenge and let the user sign in with any passkeys they have. This is what allows passkeys to be a single factor sign in, rather than just an additional factor. In general it is actually recommended to not use allow lists with passkeys or save any state after the user is signed out, so that they are free to sign in with whichever account they like when they come back.