Hi everyone!
Will iOS platform authenticator have support for PRF passkeys extension? https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension
As far as I know current implementation doesn't as we don't have access to private part of generated keys to perform some crypto operations
If you have a use case in mind for the PRF extension, please tell us about it through Feedback Assistant!
Also interesting here is blob extensions for passkeys: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Large-Blob-Extension
Clear use-cases are given in the doc, such as storing secrets for e2ee on the authenticator itself & thus allowing this to be accessed across multiple devices.
There is also a similary use case for a users private key in a crypto wallet context.
Are Apple working on making the passkey api to more closely match what is set out by FIDO in the webauthn spec?
Also interesting here is blob extensions for passkeys: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Large-Blob-Extension Clear use-cases are given in the doc, such as storing secrets for e2ee on the authenticator itself & thus allowing this to be accessed across multiple devices. There is also a similary use case for a users private key in a crypto wallet context. Are Apple working on making the passkey api to more closely match what is set out by FIDO in the webauthn spec?
There's a significant difference between a theoretical use case outlined in a spec and real world use case that someone is trying to build :). We generally don't build things just because they exist in a spec somewhere. We try to focus on things we think will be beneficial to users or developers, and hearing specifically what developers want to build helps us a lot with that!
These are definitely not theoretical use cases. Allowing client side encryption enables users to retain sovereignty over their data and service providers an ability to store it without a need or desire to view it. Data vaults are one example https://identity.foundation/edv-spec/#encrypted-storage
Companies like Bitwarden are already taking advantage of this mechanism in Chrome https://bitwarden.com/blog/prf-webauthn-and-its-role-in-passkeys . In the realm of non-custodial digital wallets it would be a big UX and security advancement removing any need to access private keys server-side, or for a user to be forced to securely store/remember a key phrase.
We would like to use PRF to protect the user data within our services by using the PRF salt as basis for the HKDF. Given the heavy penalties in case of GDPR breaches, it would really mean a lot for service providers if the user data could be protected completely by the WebAuthn authenticators. However, this would require that all web browsers/platforms support PRF (for "cloud" authenticators, the PRF extension could even be emulated by the "cloud" authenticator provider). For the moment only Google Chrome/Edge desktop versions support PRF (if the native authenticator supports HMAC-SECRET), which from a practical point-of-view renders PRF useless for the moment.
@garrett-davidson This is all but theoretical. Given the GDPR, the industry should really push PRF support like crazy.
Another use case for PRF is protecting identity wallets. PRF can be used to derive encryption keys that encrypt/decrypt identity data stored locally in a browser or remotely on some cloud storage. This currently works in Google Chrome. A demo of such a wallet can be viewed in the video embedded in a recent Yubico blog: "The first working demo of a web based EU digital identity wallet leveraging FIDO open authentication standards"
Voicing my support for this extension as well. It will open up many opportunities to use client side encryption bound to authentication with passkeys.
Hi all,
I just wanted to add onto this thread.
After further discussion with an Apple employee; while they cannot speak to future plans or timelines, the use cases for the Pseudo-random function extension (prf) in WebAuthn L3 are well-understood by their team and have "no philosophical objections to implementing."
Again, this is NOT a confirmation that Apple will indeed implement this extension into their OS', but I figured it is important information for those who have not already received the memo.
@garrett-davidson regarding real life examples - I am developing a SaaS platform for psychotherapist to help them manage their office and clients and as a part of that there is also possibility manage client session notes within the app. As that is highly sensitive data, I am encrypting it on the browser, so that there is never a plaintext version on the server. However, due to the lack of prf extension, I am unable to use passkeys to unlock this data, though I am using them to login to the app. So the UX is not that great - people can log in with passkeys, but when they want to use notes part, they need to enter a separate password, which is used to derive the encryption key.
I have a very similar use case.
And for a more general POV, for every app using zero-knowledge encryption, the PRF extension is necessary. Not only to solve the UX issue mentioned above, but this really could be a tremendous security improvement, as the encryption would not rely on the derivation of the user password (in a way or another).
