9 ms·

The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys. The co

The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys. The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise. The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article. The ideal future state is: * the provider for newly registered credentials would be a browser setting * the setting would come configured to use the OS vendor out of the box * installing a password manager providing passkeys would prompt to change the setting to use the password manager instead * one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option * there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience. The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.

fastball 2y ago
What is the benefit to Apple?
- neogodless 2y ago
  Doesn't Apple primarily want the best user experience, and the safest way to use devices? So they should get onboard with what is best for the user.
  - Borealid 2y ago
    No, Apple directly benefits in that users only get the "magical" user experience when using Apple devices. There are two perverse incentives: one for Apple to lock their users into their platform, and one for Apple to implement a "better" experience unilaterally. Apple does both of these things. Today, if I create a passkey on an Apple iPhone, and I pay Apple a monthly fee for iCloud, I can then walk over to an Apple Macbook I own and sign in to the same web site without another step. But if I don't pay Apple a monthly fee, OR the phone isn't an iPhone, OR the laptop isn't a Macbook, then I don't get that user experience. There is absolutely no technical reason that I shouldn't be able to get precisely the same level of security and precisely the same user flow without having to need all the devices to be Apple. But Apple chooses to restrict how it can happen.
    - kalleboo 2y ago
      Apple allows you to use third party apps as passkey providers
      - fastball 2y ago
        Not on their own websites, AFAIK.
    - mercutio2 2y ago
      Why do you say you have to pay a monthly fee for iCloud? None of the technology you’re discussing here requires a paid account. You may, separately, decide to sync more than the meager free quota of data on iCloud, but that’s an unrelated issue. You’re welcome to use iCloud just for keychain sync.
  - baby_souffle 2y ago
    > Doesn't Apple primarily want the best user experience, and the safest way to use devices? Presumably, yes. > So they should get onboard with what is best for the user. What happens when there’s a conflict? They usually go with the option that screws the smaller niche user base.
- daft_pink 2y ago
  If all your passkeys are synced to Apple, then it makes it really easy to use that new Apple device and really hard to use that PC/Android Phone/Meta VR headset/etc. They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(
samcat116 2y ago
Every passkey setup flow I've ever seen has allowed me to use a hardware key or the OS provided store. Am I missing something?
- Borealid 2y ago
  Have you: A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential? Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.
- berdario 2y ago
  Some flows might allow only Platform authenticators (disallowing external hardware keys) https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Platform_vs_Cross-Platform.html https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu... https://www.reddit.com/r/webauthn/comments/197ggm7/comment/ki0cxvd/ https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k... The only one that I witnessed, is the optional passkey for restoring your Whatsapp account
lxgr 2y ago
> The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari... It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation. > The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...] No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
- Borealid 2y ago
  If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is: * the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform. * the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME > there isn't even attestation that could allow relying parties to block any specific implementation This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.
  - lxgr 2y ago
    > How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? > * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time. > This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. > the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.
mikepurvis 2y ago
Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life. Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
amluto 2y ago
I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying. NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model. Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device. This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
- Borealid 2y ago
  > NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model. No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later. In order to attack a CTAP token over NFC you need to man-in-the-middle it.
  - amluto 2y ago
    In order to attack a CTAP token, I can tap it against an ordinary phone or a Proxmark or any PN532 device attached to a computer with some fairly straightforward software. There isn’t any authentication! It could be ECDH or SnakeOil-102400-super unbreakable for all an attacker cares: the attacker can just speak the protocol as specified. edit: Okay, I found the pinToken mechanism in the spec. It is, to put it politely, not a PAKE. It has a trivial DoS attack by design allowing anyone nearby to destroy an authenticator. It looks vulnerable to an attack in which someone taps a malicious token against a phone or other reader, triggering the phone to try to authenticate, and thus captures the PIN, hashed but not even salted. Oh, and I’ve personally never been prompted to set a PIN, and the UX looks miserable.
lolinder 2y ago
> passkeys were a great idea until cloud vendors waged war on hardware keys. > The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise. This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal. Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session. Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
- Borealid 2y ago
  I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors. I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor. I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".
  - deleted 2y ago
    [deleted]
  - lxgr 2y ago
    > by software not written by OS vendors. In an ideal world, I'd prefer that to. In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them. As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys. > the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor. Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing). And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.
WorldMaker 2y ago
> installing a password manager providing passkeys would prompt to change the setting to use the password manager instead iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app. It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX. It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
- kenada 2y ago
  macOS also supports the APIs, but password manager developers don’t seem willing to implement them there. I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).
  - WorldMaker 2y ago
    I'm aware of iOS' APIs because of Strongbox (iOS Keepass-compatible client), and someone also mentioned that macOS Strongbox does the same thing just fine. That is interesting that in this case it seems specifically a 1Password choice/disinterest.

fastball 2y ago

What is the benefit to Apple?

neogodless 2y ago
Doesn't Apple primarily want the best user experience, and the safest way to use devices? So they should get onboard with what is best for the user.
- Borealid 2y ago
  No, Apple directly benefits in that users only get the "magical" user experience when using Apple devices. There are two perverse incentives: one for Apple to lock their users into their platform, and one for Apple to implement a "better" experience unilaterally. Apple does both of these things. Today, if I create a passkey on an Apple iPhone, and I pay Apple a monthly fee for iCloud, I can then walk over to an Apple Macbook I own and sign in to the same web site without another step. But if I don't pay Apple a monthly fee, OR the phone isn't an iPhone, OR the laptop isn't a Macbook, then I don't get that user experience. There is absolutely no technical reason that I shouldn't be able to get precisely the same level of security and precisely the same user flow without having to need all the devices to be Apple. But Apple chooses to restrict how it can happen.
  - kalleboo 2y ago
    Apple allows you to use third party apps as passkey providers
    - fastball 2y ago
      Not on their own websites, AFAIK.
  - mercutio2 2y ago
    Why do you say you have to pay a monthly fee for iCloud? None of the technology you’re discussing here requires a paid account. You may, separately, decide to sync more than the meager free quota of data on iCloud, but that’s an unrelated issue. You’re welcome to use iCloud just for keychain sync.
- baby_souffle 2y ago
  > Doesn't Apple primarily want the best user experience, and the safest way to use devices? Presumably, yes. > So they should get onboard with what is best for the user. What happens when there’s a conflict? They usually go with the option that screws the smaller niche user base.
daft_pink 2y ago
If all your passkeys are synced to Apple, then it makes it really easy to use that new Apple device and really hard to use that PC/Android Phone/Meta VR headset/etc. They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(

samcat116 2y ago

Every passkey setup flow I've ever seen has allowed me to use a hardware key or the OS provided store. Am I missing something?

Borealid 2y ago
Have you: A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential? Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.
berdario 2y ago
Some flows might allow only Platform authenticators (disallowing external hardware keys) https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Platform_vs_Cross-Platform.html https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu... https://www.reddit.com/r/webauthn/comments/197ggm7/comment/ki0cxvd/ https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k... The only one that I witnessed, is the optional passkey for restoring your Whatsapp account

lxgr 2y ago

> The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari... It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation. > The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...] No, this "ideal state" is in fact the reality I've been experiencing for the past few months.

Borealid 2y ago
If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is: * the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform. * the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME > there isn't even attestation that could allow relying parties to block any specific implementation This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.
- lxgr 2y ago
  > How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? > * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time. > This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. > the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.

mikepurvis 2y ago

Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life. Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.

amluto 2y ago

I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying. NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model. Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device. This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?

Borealid 2y ago
> NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model. No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later. In order to attack a CTAP token over NFC you need to man-in-the-middle it.
- amluto 2y ago
  In order to attack a CTAP token, I can tap it against an ordinary phone or a Proxmark or any PN532 device attached to a computer with some fairly straightforward software. There isn’t any authentication! It could be ECDH or SnakeOil-102400-super unbreakable for all an attacker cares: the attacker can just speak the protocol as specified. edit: Okay, I found the pinToken mechanism in the spec. It is, to put it politely, not a PAKE. It has a trivial DoS attack by design allowing anyone nearby to destroy an authenticator. It looks vulnerable to an attack in which someone taps a malicious token against a phone or other reader, triggering the phone to try to authenticate, and thus captures the PIN, hashed but not even salted. Oh, and I’ve personally never been prompted to set a PIN, and the UX looks miserable.

lolinder 2y ago

> passkeys were a great idea until cloud vendors waged war on hardware keys. > The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise. This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal. Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session. Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!

Borealid 2y ago
I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors. I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor. I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".
- deleted 2y ago
  [deleted]
- lxgr 2y ago
  > by software not written by OS vendors. In an ideal world, I'd prefer that to. In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them. As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys. > the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor. Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing). And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.

WorldMaker 2y ago

> installing a password manager providing passkeys would prompt to change the setting to use the password manager instead iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app. It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX. It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.

kenada 2y ago
macOS also supports the APIs, but password manager developers don’t seem willing to implement them there. I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).
- WorldMaker 2y ago
  I'm aware of iOS' APIs because of Strongbox (iOS Keepass-compatible client), and someone also mentioned that macOS Strongbox does the same thing just fine. That is interesting that in this case it seems specifically a 1Password choice/disinterest.