Scenario Use Safari browser on macOS and trigger Webauthn authentication Select QR code authentication flows Use Android phone's passkey (with play service beta) and scan the QR code Perform UV on Android device Check the authentication response coming from the Safari on macOS Issue The authenticatorAttachment in the response is "platform". Expected behavior The authenticatorAttachment should be "cross-platfrom". According to the spec (https://w3c.github.io/webauthn/#dom-publickeycredential-authenticatorattachment), the value should be "cross-platform" since the attachment modality at the time of authenitcation is "cross-platfrom" rather than "platform". Without "cross-platform", RP cannot decide and guide for the user to register the "platform" authenticator on the macOS. I just checked this issue with Safari (16.2) on macOS (13.1). Also, you can refer related issue on the fido-dev-group: https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/XvDWBH6PhQ0

At my company, we already support passkey functionality for our users; however, there is a specific scenario that is particularly helpful/impactful for our enterprise users the ability to log in on a Windows laptop (in Chrome/Edge) using the phone as a key. When Android phones are "registered" to log in – the browser remembers them, and next time a user can pick a previously registered phone – super convenient! Unfortunately, the same doesn't work with iPhones. They work fine through QR codes, but Chrome on laptops doesn't remember iPhones, so a user has to go through a QR code each time - hard to sell this option to users from a usability perspective. Is Apple planning to support the same "remember me" option between Chrome on Windows and iPhone? I want to emphasize that in a business environment, users often control their phones but not laptops, i.e... Windows laptop with iPhone is a very typical use-case. We have many enterprise customers whose IT doesn't enable Windows Hello on laptops, so the ability to authenticate in our product by using a phone as a permanent authenticator (vs. creating a local key on a laptop) is critical.

Is it possible to use the same passkey in multiple apps? For example, a user creates a passkey for App A1 to login to service S. Then he can use the same passkey to login into service S from App A2.

When the passkey is generated with user verification required options with macOS (w/ device password and w/o/ touchId), the operation requires user prompt to perform UV with device password. This is an expected behavior. But, after successful registration, when trying to signin with auto-fill feature (conditional mediation), the signin process is failed on the RP side. RP sets UV as required (since the generated credential is protected by UV and RP would like perform MFA with UV) Safari shows the user account (which is registered before) Select the registered user account No UV is performed and Safari returns the assertion response RP rejects the assertion response since the requested options are not respected (expected UV flag is true, but currently UF flag is set as false with no UV performed). When authentication is requested with Modal UI, then the authentication performs the UV and the returned UV flag is set as true. (correct and expected behavior) Expected behavior Safari should respect UV required when handling such request with Auto-fill. FYI, I'm not tested with this scenario with other macOS (w/ touch Id).

Scenario Use Safari on macOS and then trigger Webauthn authentication with non-empty allow list Select QR code authentication flow and use Android passkey by scanning QR code and performing UV Check userhandle field in authenticator response coming from Safari. Issue: currently, the returned userHandle is empty ("") string. As a RP side, we could handle empty string as null, but some server implementation might reject such response since it's not valid value. Exepected behavior: If the authenticator does not return any userHandle to the browser, the userHandleResult (userhandle returned by the browser) should be null rather than empty string. Other observations: Chrome on macOS returns null userHandle for above scenarios which I'm thinking it's correct behavior. Safari on iOS returns populated userHandle (which is not null and empty) even the authentication is requested with non-empty allow credentials. I'm thinking that this is not the problem. See followings: https://w3c.github.io/webauthn/#assertioncreationdata-userhandleresult Also there are related discussions: https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/v6JBaTsNv08

I'm trying to run the passkeys demo app from the page Connecting to a service with passkeys, and after following the directions there, when running the app I get the following error: 2022-11-13 10:09:12.514544+0100 Shiny[1413:277579] [Authorization] ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" 2022-11-13 10:09:12.515545+0100 Shiny[1413:277317] Request canceled. When I search for this on Google, I get a bunch of results about Sign in with Apple, not about passkeys. Can anyone help me make sense of this?

Is there a demo app for using passkeys with SwiftUI? So far I've only been able to find this one using UIKit, and I can't tell if it's possible to port it to SwiftUI, or if I have to use UIKit.

WebAuthn API returns fully qualified origin of the API requester in the clientDataJSON. In case of passkey native api, which information is returned and how does it look like? I cannot find such information in anywhere. Thanks in advance.

Fantastic and informative video! I'm looking to add passkeys as an authentication option for my site, but I want to make sure that when they are used they satisfy strong authentication. I know passkeys are supposed to be interoperable across operating systems, and I know the video mentions that Apple will always require passkeys to be protected by biometrics, but how can I ensure that passkeys from other operating systems are protected by biometrics? Is there a particular claim on the passkey that contains this information, or would we need to rely on the operating system of the client/authenticator (which can be spoofed)?

Before promoting passkey registration, I would like to check whether the user device has platform authenticator (or passkey platform authenticator). While trying to search such feature in the docs, I cannot find it anywhere. Is this intended? If there is no such api, how can we know whether the user can register passkey?

I recently learned https://developer.apple.com/videos/play/wwdc2022/10092/?time=382 and don't understand why Apple thinks allowing share Passkeys would be a good feature. I feel this is a really bad practice that we allow them to share Passkeys. Is there possible the website could forbid them from sharing it?

I’m a little confused with the introduction of Passkeys. I was playing on using Sign in With Apple for my account creation and login. My understanding for passkeys is that they are deployed after the account is used as a replacement for the password. Can I create an account from passkeys or is it only bolted onto an account after it is already created through a different schema?

Wanted to clarify that WebAuthN APIs don't function on WKWebView and SFSafariViewController within native apps. The only option for native apps is the native ASAuthorizationPublicKeyCredentials... APIs. The only exception being the native Apps with web browser entitlement as per this webKit change https://bugs.webkit.org/attachment.cgi?id=453655&action=prettypatch.

I am trying to integrate passkey in my project, But I am not able to find how can I generate public and private key for specific account for specific user. I did found following resources but non of them contains public-private key generation code! Supporting passkeys Connecting to a service with passkeys Any of these resource does not contains code to generate public/private key generation code.

When trying to sign a user up using passkeys I create a request using: createCredentialRegistrationRequest when performing this request with performRequests all goes well. When a user cancels this request by pressing the X on the system modal that is presented I correctly receive a canceled event through authorizationController(controller:, didCompleteWithError:). Now if I retry the request I do not get a popup or a canceled error but instead I get the following: ["NSLocalizedFailureReason": Request already in progress for specified application identifier.] Is there a way to present the registration/signup with passkeys modal again after the user has cancelled it? For example when a user dismisses the system modal but later decides to press the "create account" button again. As far as I can see now if the user cancels the request once you can never show the modal again.

Can someone outline how new users would create a username with a passkey? Most of the video focuses on existing users but I am interested in how new users would create their username. Do they still have to set an initial password and then associate a passkey with their account?

Hi, I am trying to add passkeys to my app. According to the sample code, I need to create a passkey and verify it with the server. But what if I make a passkey successfully but fail to finish the server request? The passkey will still be stored in the keychain. Can I delete it programmatically?

I noticed the behavior of ASAuthorizationController has changed in the lasted beta. When the user only has a password but no passkey, even if I only pass in an ASAuthorizationPublicKeyCredentialAssertionRequest and no ASAuthorizationPasswordRequest, the action sheet will display the password. Is this by design? This has some impact on my implementation. Will this change again in the future?

Hi, I want to implement passkey in my app. I am wondering if there is a robust way to distinguish between these two situations: the user cancels the action sheet (ASAuthorizationController) there are no credentials at all Both situations give a canceled error. I noticed a localized string in NSError.userInfo explaining the reason in situation 2, but this is not a robust way of distinguishing between them because the behavior can change in the future.

Hi everyone, I have a website using FIDO2/WebAuthn. My current users have their FIDO credentials on the phone. As far as I understand, those credentials will not automatically synchronize with Passkeys when those users switch to iOS16 (meaning that their FIDO credential can't be used cross-device automatically). Is it true that, for example, if the keys were created with iOS15 on the phone, users will need to scan a QR Code on the desktop the first time to create the passkeys and add them to the iCloud Keychain? If this was just too confusing let me know :) the bottom line is understanding if there is a way to "migrate" existing FIDO credentials created before iOS16 to Passkeys without scanning the QR Code one time. Thanks!