5 ms·

I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provid

I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider

jaywalk 4y ago
What? Why? How would this improve anything?
convolvatron 4y ago
you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity
- arianvanp 4y ago
  The opposite. Now there is just one hardcoded SSO provider: Apple iCloud. Which means you're stuck to one provider. I'd like this to be opened up. Open spec for being able to sync passkeys
  - acdha 4y ago
    It’s Apple, Google, or Microsoft now and soon to be 1Password and others. None of those are hard-coded on the sites using it - the concern is that you can’t port keys between, say, iOS Safari and Windows Edge but you can already register keys from both because it’s not SSO but rather a different PKI scheme.
sebk 4y ago
I'm with you here and have been parroting this in just about every Webauthn thread on HN, except maybe with the exception that I think it's password manager vendors who are more interested -- several of them have joined the FIDO alliance in the past year. I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable. The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.
- 9dev 4y ago
  Had this been part of the spec, it would never have been adopted so fast. The sync fabric is so complex, so sensitive, so hard to get right, I wouldn’t want this to be part of the Passkey/WebAuthn apex anyway. Let’s see how things unfold - passkeys in itself are an incredible improvement already.
  - sebk 4y ago
    I don't disagree at all. I like that WebAuthn prioritized security and privacy over usability, and they have made improvements in usability later on (like Passkeys or hybrid transport). Bolting on security is undoubtedly worse than bolting on UX. But I also think that it's important that consumers keep actively voicing their needs and preference. I believe we'll have a good solution in this space, but until we do, I'll keep parroting the need every chance I get. Also please don't get me wrong, I don't want sync fabric establishment to be part of the WebAuthn or CTAP2 spec at all, but I do want a solution that both gives third-party sync fabric developers access to the hardware. It being a standard isn't strictly needed unless we're thinking of cross-fabric compatibility, which I think no one wants. It would certainly help with not messing up the implementation, though, but if that happens it should be something separate from WebAuthn.
- josephcsible 4y ago
  > The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. Why are you saying that would be a risk? I want that to happen, so that I'd be able to back up my passkeys on my own terms.
smw 4y ago
Then how would you authenticate to the SSO provider?
9dev 4y ago
No! For once, we have made it completely obsolete to try and obtain user databases and sell millions of credentials, because they aren’t useful for passkey enabled sites. But instead of exposing users that reuse their password across a handful of sites, you want to hand over the single master key to everyone’s digital life to the hackers??

I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider

jaywalk 4y ago

What? Why? How would this improve anything?

convolvatron 4y ago

you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity

arianvanp 4y ago
The opposite. Now there is just one hardcoded SSO provider: Apple iCloud. Which means you're stuck to one provider. I'd like this to be opened up. Open spec for being able to sync passkeys
- acdha 4y ago
  It’s Apple, Google, or Microsoft now and soon to be 1Password and others. None of those are hard-coded on the sites using it - the concern is that you can’t port keys between, say, iOS Safari and Windows Edge but you can already register keys from both because it’s not SSO but rather a different PKI scheme.

sebk 4y ago

I'm with you here and have been parroting this in just about every Webauthn thread on HN, except maybe with the exception that I think it's password manager vendors who are more interested -- several of them have joined the FIDO alliance in the past year. I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable. The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.

9dev 4y ago
Had this been part of the spec, it would never have been adopted so fast. The sync fabric is so complex, so sensitive, so hard to get right, I wouldn’t want this to be part of the Passkey/WebAuthn apex anyway. Let’s see how things unfold - passkeys in itself are an incredible improvement already.
- sebk 4y ago
  I don't disagree at all. I like that WebAuthn prioritized security and privacy over usability, and they have made improvements in usability later on (like Passkeys or hybrid transport). Bolting on security is undoubtedly worse than bolting on UX. But I also think that it's important that consumers keep actively voicing their needs and preference. I believe we'll have a good solution in this space, but until we do, I'll keep parroting the need every chance I get. Also please don't get me wrong, I don't want sync fabric establishment to be part of the WebAuthn or CTAP2 spec at all, but I do want a solution that both gives third-party sync fabric developers access to the hardware. It being a standard isn't strictly needed unless we're thinking of cross-fabric compatibility, which I think no one wants. It would certainly help with not messing up the implementation, though, but if that happens it should be something separate from WebAuthn.
josephcsible 4y ago
> The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. Why are you saying that would be a risk? I want that to happen, so that I'd be able to back up my passkeys on my own terms.

smw 4y ago

Then how would you authenticate to the SSO provider?

9dev 4y ago

No! For once, we have made it completely obsolete to try and obtain user databases and sell millions of credentials, because they aren’t useful for passkey enabled sites. But instead of exposing users that reuse their password across a handful of sites, you want to hand over the single master key to everyone’s digital life to the hackers??