4 ms·

> with good cross-platform support Not to rehash the entire previous post, but this should have a giant asterisk next to it. It's very technically cross-platfo

> with good cross-platform support Not to rehash the entire previous post, but this should have a giant asterisk next to it. It's very technically cross-platform, but there is no batch interchange format. If you use Safari, your passkeys are only synced to iCloud. You can share them via AirDrop... to other Apple users. If you lose your phone, you can recover them... if you buy another iPhone. You can use your iPhone to log in on a Windows device, that part is cross-platform. And you can add that device as a second authenticator. But there's no actual portability there. You have (limited) cross-platform support (there is no Open Source platform authenticator that I'm aware of, and I'm not aware of any platform authenticator for Linux). But you can likely use passkeys with whatever platform you want. It's just once you choose a platform, there's no way to export from that platform unless you per-site add a new authenticator.

derefr 3y ago
Passkeys are already device-bound; there would be no point in cross-ecosystem sync. They're maybe backed up to a provider's cloud, but that's in case you reformat your computer and want to restore it from backup; not for moving the passkey around. Think of a passkey as a device identity credential. It gives credential X that you can register on your backend as belonging to device Y; not to user Y. You need to additionally keep in your backend a mapping from devices to users — where almost certainly, a user HAS MANY devices. You know how, in well-thought-out auth systems, you can "sign in with a password" and "sign in with [SSO provider]", and those will result in signing into the same account, where both the password credential and the IdP subject-claim are separate "credentials" bound to that account? Each passkey is a "credential bound to the account" in that sense. You create one for each device, and they all log you into the same account. In short, they're a "third-party-ization" of the thing that Apple, Google, etc already do with their "you're trying to sign into your Apple/Google/etc account from a new device. Confirm this on an existing device" workflows — where each device creates its own separate credential, that is enrolled to your cloud account. This is that, but for any third party website, rather than just the cloud service itself.
- danShumway 3y ago
  > Passkeys are already device-bound No, they're explicitly not, they're synced to the cloud for both iOS and Android. Microsoft also plans to do cloud sync (if they don't already). Yubikeys are device identity credentials. Passkeys are user credentials, they get backed up off device. That's a really big deal that both Google and Apple have been heavily advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back when you sign into your account. They are very much user credentials rather than device credentials; anyone who has access to your iCloud can use your passkeys. Passkeys aren't bound to your iPhone, but they are inexplicably bound to your Apple devices. That's the portability problem. The major companies (Google, Microsoft, Apple) got rid of device-bound keys. But they kept the platform lock-in. > where almost certainly, a user HAS MANY devices. Speak for yourself, I have exactly one device that will work as an authenticator, and even it only works as an authenticator because I've been too lazy to install LineageOS on it. Most people own one phone and a laptop, and they frequently travel with both of them at the same time. I think Google/Microsoft/Apple went the cloud-sync direction partially in acknowledgement of the fact that "use multiple devices" doesn't really work for everyone.
  - derefr 3y ago
    > Passkeys are bigger than that, they're not device bound. That's a really big deal that both Google and Apple have been advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back. You're interpreting "device" differently than I am, here. Maybe let me use a different word. There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.") Unlike humans, these device "souls" can leave and come back (restoring from backup) or be reincarnated into a different body (transferring a backup to a new hardware device.) What Apple, Google, etc. are claiming is that passkey credentials are bound to the soul of your device — the unique installation session that resulted in a unique product-key "activation" in their servers — rather than to the body of your device. So wherever the installation goes, the passkeys go along with it. But this does not mean that passkeys are portable between installations. They still inherently represent "devices" — just semantic, abstract devices, that may be incarnated at any given time in zero or one physical hardware devices. And, again, this is exactly how Apple's and Google's own device enrolment for sign-in to their respective cloud accounts works. I have devices listed in my iCloud account that currently have no "incarnated" form — the hardware was wiped, sold, and is now being used by someone else! — but those unique installations do still "exist" and could be "reincarnated", as long as I keep my iCloud Backup of them.

derefr 3y ago

Passkeys are already device-bound; there would be no point in cross-ecosystem sync. They're maybe backed up to a provider's cloud, but that's in case you reformat your computer and want to restore it from backup; not for moving the passkey around. Think of a passkey as a device identity credential. It gives credential X that you can register on your backend as belonging to device Y; not to user Y. You need to additionally keep in your backend a mapping from devices to users — where almost certainly, a user HAS MANY devices. You know how, in well-thought-out auth systems, you can "sign in with a password" and "sign in with [SSO provider]", and those will result in signing into the same account, where both the password credential and the IdP subject-claim are separate "credentials" bound to that account? Each passkey is a "credential bound to the account" in that sense. You create one for each device, and they all log you into the same account. In short, they're a "third-party-ization" of the thing that Apple, Google, etc already do with their "you're trying to sign into your Apple/Google/etc account from a new device. Confirm this on an existing device" workflows — where each device creates its own separate credential, that is enrolled to your cloud account. This is that, but for any third party website, rather than just the cloud service itself.

danShumway 3y ago
> Passkeys are already device-bound No, they're explicitly not, they're synced to the cloud for both iOS and Android. Microsoft also plans to do cloud sync (if they don't already). Yubikeys are device identity credentials. Passkeys are user credentials, they get backed up off device. That's a really big deal that both Google and Apple have been heavily advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back when you sign into your account. They are very much user credentials rather than device credentials; anyone who has access to your iCloud can use your passkeys. Passkeys aren't bound to your iPhone, but they are inexplicably bound to your Apple devices. That's the portability problem. The major companies (Google, Microsoft, Apple) got rid of device-bound keys. But they kept the platform lock-in. > where almost certainly, a user HAS MANY devices. Speak for yourself, I have exactly one device that will work as an authenticator, and even it only works as an authenticator because I've been too lazy to install LineageOS on it. Most people own one phone and a laptop, and they frequently travel with both of them at the same time. I think Google/Microsoft/Apple went the cloud-sync direction partially in acknowledgement of the fact that "use multiple devices" doesn't really work for everyone.
- derefr 3y ago
  > Passkeys are bigger than that, they're not device bound. That's a really big deal that both Google and Apple have been advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back. You're interpreting "device" differently than I am, here. Maybe let me use a different word. There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.") Unlike humans, these device "souls" can leave and come back (restoring from backup) or be reincarnated into a different body (transferring a backup to a new hardware device.) What Apple, Google, etc. are claiming is that passkey credentials are bound to the soul of your device — the unique installation session that resulted in a unique product-key "activation" in their servers — rather than to the body of your device. So wherever the installation goes, the passkeys go along with it. But this does not mean that passkeys are portable between installations. They still inherently represent "devices" — just semantic, abstract devices, that may be incarnated at any given time in zero or one physical hardware devices. And, again, this is exactly how Apple's and Google's own device enrolment for sign-in to their respective cloud accounts works. I have devices listed in my iCloud account that currently have no "incarnated" form — the hardware was wiped, sold, and is now being used by someone else! — but those unique installations do still "exist" and could be "reincarnated", as long as I keep my iCloud Backup of them.