@SoloX Can you share any details ? How did you solve it ? Thanks

Thank you for the quick response, @garrett-davidson. Below is a piece of code that we are trying to use, along with comments to clarify the situation. Your comments will be greatly appreciated. // Example: We visit https://example.com and press the register button, which internally triggers `navigator.credentials.create()`. override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { self.request = registrationRequest as! ASPasskeyCredentialRequest let response = ASPasskeyRegistrationCredential( // What string should be used here? example.com or https://example.com? // Is this the correct documentation? Refer to: https://www.w3.org/TR/webauthn-2/#relying-party-identifier relyingParty: self.request.credentialIdentity.serviceIdentifier.identifier, // Is this the correct documentation for `clientDataHash`? See: https://www.w3.org/TR/webauthn-2/#collectedclientdata-hash-of-the-serialized-client-data clientDataHash: self.request.clientDataHash, // Is this the correct documentation? Check: https://www.w3.org/TR/webauthn-2/#credential-id credentialID: Data(UUID().uuidString.utf8), // Is this the correct documentation? See: https://www.w3.org/TR/webauthn-2/#sctn-generating-an-attestation-object // Should the attestationObject be a CBOR map in bytes? attestationObject: Data() ) self.extensionContext.completeRegistrationRequest(using: response) }

After a few days of research, we finally found out why it didn't work. The problem lies here: https://www.w3.org/TR/webauthn-3/#flags According to the official documentation, Bits 3-5 are reserved for future use (RFU2), and they MUST remain as zeros. However, in this source https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Authenticator_data,) those bits are used. It seems that on iOS, if those bits are zeros, you always get an error. This aspect is not mentioned anywhere.

Hey @codecomet, Looks like you are not following the specs, check this https://www.w3.org/TR/webauthn-2/#sctn-attestation When you are constructing the AttestationObject the resulting CBOR must be an Ordered Dictionary that has the order: fmt attStmt authData Looks like other services don't care about this, but Google does :))) You are welcome.

I have submitted a feedback FB13165119 (Passkeys don't respect WebAuthn specs (RP ID)) Here is the answer: Are you seeing this in Safari or in an app associated with example.com? I haven't checked it in other apps only in Safari. Is the RPID of the registered passkey actually foo.example.com or did it get registered for example.com? I register the Passkey for foo.example.com and NOT example.com Did you save the passkey's credential identity to the system through ASCredentialIdentityStore, and if so, what serviceIdentifier did you use? Yes. I save the Passkey with ASCredentialIdentityStore and I set the same value that I get from ASPasskeyCredentialRequest.credentialIdentity.serviceIdentifier.identifier, in this case the foo.example.com Is the unexpected passkey being shown on the system QuickType bar or only when pulling up the full list of credentials? The unexpected passkey is being shown on the system QuickType bar as a suggestion to fill when I visit the bar.example.com And the most strange thing is that when I use the wrong Passkey on bar.example.com in func prepareInterfaceToProvideCredential(for credentialRequest: ASCredentialRequest), the credentialRequest.credentialIdentity.serviceIdentifier.identifier == "foo.example.com"

The problem is that the "Key" icon in the QuickType bar is not appearing. UPDATE: To make the system show the "Key," you need to feed the ASCredentialIdentityStore with ASOneTimeCodeCredentialIdentity using a serviceIdentifier that matches the domain or URL. To be honest, this is not ideal. Now, we need to have a domain or URL to be able to show the autofill. However, according to the Key-Uri-Format, we don't have a domain or URL when setting up 2FA.