Okay, I fixed my problem with this. You need to set the BE (Backup Eligible) and BS (Backup State) flags to 1 in the authData. I also set AT, UV and UP. A few other tips, not sure essential: Use the text tags: fmt, attestStmt, authData to identify response statements in attestationObject instead of the CTAP integer tags Use fmt:none, attestStmt: {} Check system console if you get errors. It clearly indicated "authData flag missing". Didn't tell me which one, but not hard to figure out.

Getting the system log working solved my root problem with a helpful message from com.apple.AuthenticationServices.Helper that my ASPasskeyRegistrationCredential was missing a required flag. Setting Backup Eligible and Backup State authData flags to 1 allowed my registration to succeed. Note sure why I didn't find anything on my first look at System Log. Originally, my AutoFill extension was attached to a Made for iPad StoryBoard app, but that was not entirely functional on the Mac. After I attached to a container app for native Mac it worked correctly and I found the log message, though some generated within my extension still seemed to be missing and some parts were redacted. Other point that threw me off was the iOS version was not showing my UI after I hit the Continue button. I didn't care because the data dumps I was interested in were in the prepareInterface call. Eventually, I realized that tap Continue a second time would prepareInterface again and then show my extension view. I think maybe this is a timing issue related to debugger attaching. About 1 in 10 times it would go to the view with a single Continue tap. This is all proof of concept right now, so probably can fix if need be. Or, maybe just goes away in release.

Any headway on this? I am seeing same issue on test www site I have set up. At this point I am guessing there is some problem with the attestationObject I am passing to ASPasskeyRegistrationCredential(). Working through trial and error. It is a little tricky to understand how the Authenticator duties documented in https://www.w3.org/TR/webauthn-2/ are divided up between the system and the credential provider.

Thanks, I should have mentioned that I also tried OSLog and could not see any output in the console app. All I did was: let logger = Logger() logger.error("authFill some text") Now, I am realizing the outward behavior is a little different on MacOS, so possibly prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest) is not executing on MacOS (Designed for iPad). On both systems, it is popping "Create a passkey" dialog and letting me choose my provider and continue. But on MacOS it then displays my CredentialProviderViewController view. That never appears on iOS. I just get the desired callback to prepareInterface. I will investigate further. At this point, I am just trying to understand the webauthn/fido flow and implement my own key management and signing. I guess I can do that just as well on iOS, and worry about MacOS later.

The nil distinguishedNames was for the NSURLAuthenticationMethodServerTrust method, as expected. The one thing I have discovered as I get old, is I do not see things that are right before my eyes! Also, I was sort of expecting it not to be there because Safari on MacOS had offered me option to choose a client certificate with wrong issuer. However, that may have been due to other problems.

This question was wrong. distinguishedNames is only nil for the first challenge, but the second challenge contains the DER encoded CA names as expected. I still need to investigate why Safari seemed to ignore, but at least the list is being delivered.