Hey! Is it possible to test passkeys against a locally running server in simulator with self-signed certificate? As far as I can tell, the certificate is trusted on the Simulator and Safari has no trouble communicating with the server or fetching the apple-app-site-association file. The error I'm getting is ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" Error: ["NSLocalizedFailureReason": Application with identifier FAKETEAMID.com.example.apple-samplecode.Shiny is not associated with domain webauthn-api.local] When running the Shiny example app. There is an apple-app-site-association available in https://webauthn-api.local:7001/.well-known/apple-app-site-association: { "webcredentials": { "apps": [ "FAKETEAMID.com.example.apple-samplecode.Shiny" ] } } And in the Associated Domains, I've added: webcredentials:webauthn-api.local:7001?mode=developer I saw here https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_associated-domains that to use a local server with the apple-app-site-association, one should add ?mode=developer to the entitlement. However, looking at the logs for the server, the simulator does not seem to ever attempt fetching /.well-known/apple-app-site-association file, so the developer mode does not seem to have any effect. Is the developer mode supposed to work with webcredentials service. Documentation linked above doesn't make any exclusions for that.

As I understand, passkeys are compatible with WebAuthn. However, the iOS APIs look somewhat different than the browser WebAuthn APIs. I'm mostly confused on how the PublicKeyCredentialCreationOptions (traditionally generated server side) from WebAuthn maps to iOS APIs. Specifically: How to specify in ASAuthorizationPlatformPublicKeyCredentialProvider#createCredentialRegistrationRequest which cryptographic algorithms the Relying Party supports (pubKeyCredParams)? Or is there a specific one that the server needs to support to be compatible with passkeys, as it can't be provided? The userID for ASAuthorizationPlatformPublicKeyCredentialProvider#createCredentialRegistrationRequest looks like an username in "Supporting passkeys" documentation ("anne_johnson"). Is this error in the documentation? In WebAuthn, the user ID for PublicKeyCredentialCreationOptions is described as "The user handle of the user account entity. A user handle is an opaque byte sequence with a maximum size of 64 bytes, and is not meant to be displayed to the user.". Specifically it states that "The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address.". Is the userID in createCredentialRegistrationRequest equivalent to WebAuthn PublicKeyCredentialCreationOptions.user.id, or something different? If it is equivalent, then I think the supporting passkeys documentation should not suggest using username there, as it's clearly in violation of WebAuth standard. If it's not equivalent, what then is the equivalent of that in the iOS APIs? Is there any documentation on the QR based authentication flow? So this would be a case where I want to use a Windows computer to sign in to a website using a passkey from my iOS device. I saw it demoed in several videos, but haven't found any documentation to accompany it. How does one generate the QR code (in the demo it was browser which seemed to have built-in support for that, but let's say it would be needed in a native application running on a game console or Smart TV)? Are there any protections against phishing in this flow? Would it be possible for me to send a picture of the QR code to someone remotely and have them scan it and use their passkey to sign in? If passkeys can be shared via AirDrop/iMessages, how can they be secure from phishing? If someone asks me to share my passkey with them and I comply, how is it different and more phishing resistant compared to someone asking for my password and me complying? I've seen several posts go around this question saying that for passkeys to be adopted, they need to have the same versatility than passwords. I accept that, but if passkeys can be shared with anyone having iOS device, they can't eliminitate phishing related problems.