Hi, When attempting to perform a credential registration, I constantly get the error Application with identifier <...> is not associated with domain <domain> I've verified the following: The file is present on the required URL path https://123.com/.well-known/apple-app-site-association { "webcredentials": { "apps": [ "<PREFIX>.bundleID" ] } } Added the Capabilities to my domain Confirmed that the CA is valid and there are no redirects. Am I missing something? My device is able to properly access the file

Can I add a lock screen on my iOS app? my requirement is : whenever a user opens the app, he/she need to unlock the app first then only he/she can operate the app.

In the same way that servers become a target when they contain secrets as mentioned in "Move beyond passwords" video, won't this make all of a person's Apple devices an even bigger target as they would provide ready access to the Keychain contents? When this is rolled out it will be imperative to no longer allow weak device authentication methods since this would make the iCloud Keychain and contents vulnerable from any single device with access to the keychain.

I have a very specific problem with multiple associated domains + password autofill and have not been able to find documentation regarding this. Basically my app has 3 associated domains: domainA, domainB and domainC. All are set up correctly with an apple-app-site-association file and links from any of these domains are recognised and handled by the app as expected (so far so good). The issue is that in password autofill (in the default OS and 3rd party managers), domainC always appears as the association. The order of applinks in the entitlements file does not affect which domain appears in the password manager. The only "pattern" I found here is that it seems the longest domain (in this case domainC) is the one appearing in the manager but could not find any documentation confirming this. Does anyone have any experience with password autofill?

Regarding the beta feature of storing WebAuthn passkeys in the iCloud Keychain, does anybody know if the unencrypted passkeys ever leave the secure enclave, getting stored in RAM or anything? With traditional WebAuthn on a Yubikey or similar device, my understanding is that the private key never leaves the Yubikey, that the requester just inputs the ID of the passkey they'd like to use and supplies a challenge to sign to the Yubikey, and the Yubikey spits out the signed challenge. That way, even if an attacker has root access to your machine, they still can't get that passkey. I'm hoping it works a similar way for iCloud Keychain passkeys: that the encrypted passkey and the challenge are fed to the secure enclave, which then decrypts the encrypted passkey, and then uses it to sign the challenge and then spits out the result, all with the unencrypted passkey never leaving the secure enclave. But I can't find anything definitively stating this. Anyone know for sure / have sources to back it up?

I add Webauthn authentication for the website. Faced the fact that TouchId on MacOS does not work cross-browser. If the authenticator was registered in Chrome, then I can only log in to Chrome. When I try to log in with TouchId in Safari, I get an error (found no credentials on this device). Conversely, if the authenticator is registered in Safari, then I can only log in to Safari, but I get an error in Chrome. To register the authenticator, I call navigator.credential.create (), with the parameters: { "rp": { "name": "localhost", "id": "localhost" }, "user": { "id": Unit8Array, "name": "alex", "displayName": "alex" }, "attestation": "none", "pubKeyCredParams": [ { "type": "public-key", "alg": -7 } ], "timeout": 60000, "authenticatorSelection": { "userVerification": "preferred", "requireResidentKey": false, "authenticatorAttachment": "platform" }, "challenge": Unit8Array, "excludeCredentials": [ { "type": "public-key", "id": Unit8Array } ], "status": "ok", "errorMessage": "" }

Does Passkeys in icloud keychain require website to support webauthn ? Also how is this different from the javascript based webauthn implementation ?

Hi Developers, I am wondering how is it possible for other smartphone-based FIDO authenticators to use the same iCloud Keychain storage as Passkey does so those credentials can be used on non-apple devices too, and also on the smartphone at the same time. There are some other iOS authenticators that have implemented BLE and are working on all devices including Windows, but the problem is that those apps cannot support signing in to the website on the smartphone itself (neither in apps nor inside the browser) using the previously registered credential of 'cross-platform' type.

Can password less authentication to mac desktop be configured using third party authenticator that manages private and public key lefecycle ? https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication

I tried to use Passkeys with our own FIDO-Server, but i encountered a problem. After the user confirmed the authenticationRequest created with createCredentialAssertionRequest you get a ASAuthorizationPlatformPublicKeyCredentialAssertion. When i send the contents of it to our sever it fails, because it doesn't known which credential public key it should use to verify the signature. The browser webauthn API returns something like this: { "id": "...", "rawId": "...", "type": "public-key", "response": { "authenticatorData": "...", "clientDataJSON": "...", "signature": "...", "userHandle": "..." } } where id is the credential id used to sign the challenge, which our FIDO-Server can use to look up the public-key in its database. With the current state of the iOS API our server would need to look up all public keys for the user and then try one by one in order to verify the signature. So my question is, am i missing something? Or is this intended behaviour?

When retrieving the ASAuthorizationPlatformPublicKeyCredentialRegistration, the decoded fmt value of rawAttestationObject is none instead of apple. Is this currently expected?

In the recent Move Beyond Passwords developer video, a demo application, called 'Shiny' is shown as part of the lecture. It's stated in the transcript of the video that the source code for the demo application can be found in the related links posted with the video. However, it does not appear that such a link exists. Is this demo application source available anywhere else? If not, will it be posted at a later date? Thanks.

It's currently possible to use a security key (ex. Yubikey 5 NFC) with an iPhone via NFC, but such functionality is seemingly not possible on any current versions of MacOS. Is support for NFC hardware authenticators (over an NFC-to-USB interface/device, such as the ACS ACR122U) planned for MacOS Monterey or any future release?

Hi, I've been recently testing the new WebAuthn support in ASAuthorizationController. I've noticed a small UI inconvenience in my app. The biometric modal displayed on assert request shows: Do you want to sign to "" as "marcin"? or Choose an account to sign in to "". when having more than one key enrolled. Looks like the relyingPartyIdentifier is not used. Is there any other property I should set to ensure the message contains the right service identifier? Many thanks!

Hi, Currently, Passkeys/WebAuthn API is behind a feature toggle. In iOS, turn on the Syncing Platform Authenticator switch under Settings > Developer. The Developer menu is available on your device when you set it up as a development device in Xcode. Is this API going to be enabled by default in the official iOS 15 release?

Hi, I'm playing with the new improvements to the ASAuthorizationController allowing to leverage WebAuthn API (e.g. ASAuthorizationPlatformPublicKeyCredentialRegistration and ASAuthorizationPlatformPublicKeyCredentialAssertion). I've spotted an odd behaviour when validating assert requests. Here is a small snippet of what's happening in my app: // requesting assertion         let publicKeyCredentialProvider = ASAuthorizationPlatformPublicKeyCredentialProvider(             relyingPartyIdentifier: response.rp.id         )         let assertionRequest = publicKeyCredentialProvider.createCredentialAssertionRequest(challenge: response.challenge) ... // in delegate `assertRequest` is being sent to the server             let assertRequest = AssertRequest(                 user: user,                 signature: credentialAssertion.signature,                 authData: credentialAssertion.rawAuthenticatorData,                 clientData: credentialAssertion.rawClientDataJSON,                 userId: credentialAssertion.userID             ) According to "5.1.4 Use an Existing Credential to Make an Assertion - PublicKeyCredential’s [[Get]] Method" of the WebAuthn spec, the ClientData field should contain type "webauthn.get", but looks it always has "webauthn.create" value and fails my validation. Has anyone else experienced similar issue? I was testing my app on the latest Xcode 13 beta2 and running the app on iOS 15 beta2.