Hi, Is there a guideline from Apple to prevent re-enrollment from same RP and same user Id so that we dont create multiple passkeys for same user account, We have a use case within app to create Passkeys on successful Login, but currently there is no API[ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest] available to pass excludedCredentials for the user Id sent by RP[https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialcreationoptions-excludecredentials] so that iOS can avoid creating new Passkeys for same User Id and same RP.
If we end up creating multiple Passkeys for same RP and same User Id,basically RP has to maintain all Passkeys's publickey and credIds at their end, leading to authentication complexity.
Also,Due to re-enrollment for same user with same RP, this leads to authentication failures[as user might choose diff Passkey-CredId from Modal than the one for which Challenge is requested for] until RP supports truly discoverable credentials.
We could say to replace Passkeys during subsequent creation but it would invalidate passkeys already shared to others or in sync'ed devices on web[that might work based off of storedCredId] which would be already creating passkeys or adopt webAuthN on different browsers and create new credential there as well.
But, ASAuthorizationSecurityKeyPublicKeyCredentialRegistrationRequest has excludedCredentials though.
Passkeys are always discoverable and always synced, so you generally shouldn't need to prompt to create additional passkeys if the user's account already has at least one.
Being able to silently ask the device whether passkeys exist for a given account without user consent would be a privacy issue. The WebAuthn spec tries to make this more privacy-preserving by proceeding with the full operation in the UI, so the user thinks they're creating a new credential, but under the hood returning an error to the developer (Step 3.1 in authenticatorMakeCredential on the linked page). This creates a poor user experience as the user believe they're creating an additional passkey but in reality they're only going through the motions after an error has already occurred.
Regardless of whether using excludeCredentials or not, it's difficult to create a good experience today when always prompting to create new passkeys. It's better to be more mindful about when to offer creating additional passkeys after the first one (e.g. if the user performed a cross-platform sign in, they may want to register an additional passkey on the current device).