9 ms·

Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites supp

Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace (https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/), making it passwordless login instead of 2FA is trivial and fully supported by webauthn. What’s different about this?

jrockway 4y ago
Reading the linked page, it certainly looks very similar. I've also implemented WebAuthn from scratch and the term "relying party" is burned into my brain, and this document also uses that term. It's a reasonable term to use in any authentication context, though, so not a smoking gun I guess. WebAuthn continues to work great on iOS and Mac OS, so I'm not sure there's a good reason to add some other new standard. (Though I do have the controversial opinion of wanting Apple to share my credentials between all devices. I have my iPad, iPhone, Macbook, and portable security key all enrolled in SSO. I don't mind this but I feel like it probably hinders adoption over an easily-hackable pasword that you just remember.)
- tialaramex 4y ago
  Relying Party is the jargon for the entity that gets to rely on the fancy cryptographic technology to determine something that would otherwise be difficult / expensive / unreliable. They're relying on the maths working, and on certain other parties doing their jobs correctly. Everybody here is a Relying Party when they use HTTPS. The Web PKI promises that this is really news.ycombinator.com to you, the HN reader, so long as the math works (RSA, Elliptic Curve Cryptography and likely AES) and so long as your browser vendor did their job, and the Issuing CA (DigiCert) did their job. Relying Parties should ideally know why their trust is well-founded. For example, in the Web PKI examining this cryptography is the job of the Internet Research Task Force (related to the IETF), the browser vendors are responsible to you directly, and the Root CAs are overseen by m.d.s.policy, run by Mozilla on behalf of their users and everybody else's users.
anony999 4y ago
>> Apple has described Passkey as a new kind of credential in the iCloud keychain. The technology is based on the Web Authentication API (WebAuthn), a rapidly emerging standard that uses public key cryptography instead of passwords for authenticating users to websites and applications. Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect
- swamp40 4y ago
  Same as what they did with Bluetooth and AirTags, AirPods, etc. They start with the standardized technology, do their little twist (which usually involves fixing some standardized bug that affects performance and people have been complaining about for years), and patent it.
- deleted 4y ago
  [deleted]
aseipp 4y ago
Passkeys are available for general use in any application through the system frameworks, not just the browser; they simply use WebAuthn under the hood, but it's meant to expand support outside of the browser for more apps in more use cases. I wrote another comment elsewhere but there are some other issues with using WebAuthn as a primary authentication mechanism right now, especially things like new device enrollment when using platform authenticators (not trivial but not what people are used to), so most people opt to design it as a 2FA mechanism since that normally fits into existing designs easier ("just another auth device" like TOTP or SMS.) So Passkeys will help smooth that a bit for Apple users. Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. If you can use WebAuthn today in the browser and handle new device enrollment and have designed with it in mind as a primary auth mechanism, you're way, way ahead of the curve. This is just Apple's attempt to help kick the can further down the road for their users; you may not need to use Passkeys at all. There's just more to do before we can actually use WebAuthn as the basis to replace passwords in more places.
- judge2020 4y ago
  > Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE connection so that your phone can sign the login request remotely.
  - kps 4y ago
    I'm writing this on a non-Apple computer that doesn't have any radios. Now what?
    - drexlspivey 4y ago
      What exactly is your point? You can just add a yubikey or any other device that uses WebAuthn to the service you want to authenticate with.
tialaramex 4y ago
As far as I can see this is Apple's (thus macOS / iOS) platform for FIDO, whereas WebAuthn does FIDO for the Web. So, if you have macOS or iOS software for Mailpace, this is a way to have the same workflow for that as you get with WebAuthn for the web site. Android likewise has an API for apps to get this, as well as the Chrome browser on Android having WebAuthn, and if you have apps on both platforms it might make sense to do that there too. Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS. So, GitHub won't get your Facebook credentials because github.com and facebook.com are different DNS names. Likewise "The 100% Legit Mailpace App" on iOS can't get the credentials for "Albert's Real Mailpace App" because they have some different internal iOS ID. At the backend, validation is pretty similar except the RPID is different, and you'll need to read the documentation carefully to figure out what the RPID is for these app APIs, if you have a pile of magic numbers for "your" app it's probably one of those. You don't get to specify, because the whole point is that nobody can impersonate your app (well, obviously on an iPhone Apple could impersonate it, and on Android Google could)
- dwaite 4y ago
  > Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS. The native APIs on Android, Apple and Microsoft platforms leverage relying party IDs which are web origins (e.g. https://github.com https://github.com) whether doing native or web apps. The same native API is typically used by say Github Desktop as say the Chrome Browser. A native app needs an entitlement and a file on the web server to enable functionality for particular domains. A browser gets an entitlement to request credentials for all domains.
deleted 4y ago
[deleted]
dwaite 4y ago
WebAuthn is a Web-facing Javascript API for accessing passkeys, which it calls Public Key Credentials. Technically, a Passkey is 'just' a key pair and other authentication information, associated with a web origin. It's meant to be a broad consumer facing term that resonates similarly with 'passwords' to convey its similar usage. Apple platforms, along with Android and Windows, are implementing a system that synchronizes passkeys within their respective ecosystems. They are adding ways you can entitle an application to work on behalf of a web domain, and thus get native access to register and authenticate with passkeys as well. A Yubikey or other FIDO device has been doing hardware-bound passkeys for ages. They just didn't use that term, instead calling them FIDO credentials. The above platforms are also working on processes to allow usage across ecosystems - for instance, using your iPhone to sign into a Windows desktop.

jrockway 4y ago

Reading the linked page, it certainly looks very similar. I've also implemented WebAuthn from scratch and the term "relying party" is burned into my brain, and this document also uses that term. It's a reasonable term to use in any authentication context, though, so not a smoking gun I guess. WebAuthn continues to work great on iOS and Mac OS, so I'm not sure there's a good reason to add some other new standard. (Though I do have the controversial opinion of wanting Apple to share my credentials between all devices. I have my iPad, iPhone, Macbook, and portable security key all enrolled in SSO. I don't mind this but I feel like it probably hinders adoption over an easily-hackable pasword that you just remember.)

tialaramex 4y ago
Relying Party is the jargon for the entity that gets to rely on the fancy cryptographic technology to determine something that would otherwise be difficult / expensive / unreliable. They're relying on the maths working, and on certain other parties doing their jobs correctly. Everybody here is a Relying Party when they use HTTPS. The Web PKI promises that this is really news.ycombinator.com to you, the HN reader, so long as the math works (RSA, Elliptic Curve Cryptography and likely AES) and so long as your browser vendor did their job, and the Issuing CA (DigiCert) did their job. Relying Parties should ideally know why their trust is well-founded. For example, in the Web PKI examining this cryptography is the job of the Internet Research Task Force (related to the IETF), the browser vendors are responsible to you directly, and the Root CAs are overseen by m.d.s.policy, run by Mozilla on behalf of their users and everybody else's users.

anony999 4y ago

>> Apple has described Passkey as a new kind of credential in the iCloud keychain. The technology is based on the Web Authentication API (WebAuthn), a rapidly emerging standard that uses public key cryptography instead of passwords for authenticating users to websites and applications. Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect

swamp40 4y ago
Same as what they did with Bluetooth and AirTags, AirPods, etc. They start with the standardized technology, do their little twist (which usually involves fixing some standardized bug that affects performance and people have been complaining about for years), and patent it.
deleted 4y ago
[deleted]

aseipp 4y ago

Passkeys are available for general use in any application through the system frameworks, not just the browser; they simply use WebAuthn under the hood, but it's meant to expand support outside of the browser for more apps in more use cases. I wrote another comment elsewhere but there are some other issues with using WebAuthn as a primary authentication mechanism right now, especially things like new device enrollment when using platform authenticators (not trivial but not what people are used to), so most people opt to design it as a 2FA mechanism since that normally fits into existing designs easier ("just another auth device" like TOTP or SMS.) So Passkeys will help smooth that a bit for Apple users. Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. If you can use WebAuthn today in the browser and handle new device enrollment and have designed with it in mind as a primary auth mechanism, you're way, way ahead of the curve. This is just Apple's attempt to help kick the can further down the road for their users; you may not need to use Passkeys at all. There's just more to do before we can actually use WebAuthn as the basis to replace passwords in more places.

judge2020 4y ago
> Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE connection so that your phone can sign the login request remotely.
- kps 4y ago
  I'm writing this on a non-Apple computer that doesn't have any radios. Now what?
  - drexlspivey 4y ago
    What exactly is your point? You can just add a yubikey or any other device that uses WebAuthn to the service you want to authenticate with.

tialaramex 4y ago

As far as I can see this is Apple's (thus macOS / iOS) platform for FIDO, whereas WebAuthn does FIDO for the Web. So, if you have macOS or iOS software for Mailpace, this is a way to have the same workflow for that as you get with WebAuthn for the web site. Android likewise has an API for apps to get this, as well as the Chrome browser on Android having WebAuthn, and if you have apps on both platforms it might make sense to do that there too. Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS. So, GitHub won't get your Facebook credentials because github.com and facebook.com are different DNS names. Likewise "The 100% Legit Mailpace App" on iOS can't get the credentials for "Albert's Real Mailpace App" because they have some different internal iOS ID. At the backend, validation is pretty similar except the RPID is different, and you'll need to read the documentation carefully to figure out what the RPID is for these app APIs, if you have a pile of magic numbers for "your" app it's probably one of those. You don't get to specify, because the whole point is that nobody can impersonate your app (well, obviously on an iPhone Apple could impersonate it, and on Android Google could)

dwaite 4y ago
> Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS. The native APIs on Android, Apple and Microsoft platforms leverage relying party IDs which are web origins (e.g. https://github.com https://github.com) whether doing native or web apps. The same native API is typically used by say Github Desktop as say the Chrome Browser. A native app needs an entitlement and a file on the web server to enable functionality for particular domains. A browser gets an entitlement to request credentials for all domains.

deleted 4y ago

[deleted]

dwaite 4y ago

WebAuthn is a Web-facing Javascript API for accessing passkeys, which it calls Public Key Credentials. Technically, a Passkey is 'just' a key pair and other authentication information, associated with a web origin. It's meant to be a broad consumer facing term that resonates similarly with 'passwords' to convey its similar usage. Apple platforms, along with Android and Windows, are implementing a system that synchronizes passkeys within their respective ecosystems. They are adding ways you can entitle an application to work on behalf of a web domain, and thus get native access to register and authenticate with passkeys as well. A Yubikey or other FIDO device has been doing hardware-bound passkeys for ages. They just didn't use that term, instead calling them FIDO credentials. The above platforms are also working on processes to allow usage across ecosystems - for instance, using your iPhone to sign into a Windows desktop.