4 ms·

I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to

I addressed this in the post - neither is available across all major browsers: https://backalleycoder.com/posts/passseeds-an-experiment-in-hijacking-passkeys-to-unlock-cryptographic-use-cases/#why-not-use-the-webauthns-prf-or-large-blob-features https://backalleycoder.com/posts/passseeds-an-experiment-in-... Ironically, you could make a pollyfill for the PRF functionality with this.

csuwldcat 9mo ago
Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...
- notorious_pgb 9mo ago
  You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.
notorious_pgb 9mo ago
Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself. The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.

csuwldcat 9mo ago

Saw your post above - I didn't "assert falsehoods", both are missing major browser support: https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_prf https://caniuse.com/mdn-api_credentialscontainer_get_publick... https://caniuse.com/mdn-api_credentialscontainer_get_publickey_option_extensions_largeblob https://caniuse.com/mdn-api_credentialscontainer_get_publick...

notorious_pgb 9mo ago
You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on. Apologies for the brash statement earlier; that was wrong of me.

notorious_pgb 9mo ago

Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself. The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.