sign browser key iff biometrics/os account passcode verified (mimic passkeys in the browser and build on its implementations in browsers/OS)

[r-jo]

Hi,

• passkeys is a new tech (based on webauthn) that may push the security space towards using pass managers on trusted devices
• it could be called device based security, where os account passcode (and the pass manager recovery) is all a user need for accessing anything
• passkeys are typically ecdsa private keys that are synced and stored in pass managers, I guess soon they will be exportable too
• in spite of sync, cloud storage and exports, it has advantages even over pass manager managed strong passwords

Above mentioned transition of webauthn leaves space for web crypto to step up one little step with biometrics.
The original idea of webauthn with local private keys could be easily mimiced with a little web crypto extension.
It could be as simple as one simple function which could reuse the browser / os implementations from passkeys:

signIfUserVerified(algorithm, privateKey, dynamicChallenge, osVerificationOption)

where

• algorithm like EcdsaParams object
• private key would be a CryptoKey (like ecdsa private key), previously created and stored in indexed db
• dynamic challenge would be a client or server secure random challenge (the data) to sign over
• osVerificationOption would be an enum like: STRONG, ANY
  I am not sure what webauthn implementations do, it could be possible for the sake of simplicity that we do not define any verification options at all. I found these links for apple, google, microsoft and it seems to be eclectic. Browsers as native apps may try to differentiate according to platforms. Like a weak face unlock is not strong but fingerprints, passcodes are... the implementations may change in the future, there may remain only strong ways... I would think for server side challenges we could use STRONG, for client side challenges ANY.
  https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthentication
  https://source.android.com/docs/security/features/biometric
  https://learn.microsoft.com/en-us/windows/win32/api/winbio/nf-winbio-winbioverify

The browser would sign over the challenge with private key if and only if the os account owner verifies its identity with biometrics or by any means (passcode). If it is a privacy issue, if for any reasons the identification failed (not possible, no biometrics, failed identification) it could just return null. No device capability sniffing.

Biometrics or device passcode verification by the OS would add a second factor to existing crypto key usage.
With server side storage of the public key and server side generation of the random challange it would be pretty secure.
As an extra, storing the public key on the client there could be implemented a client side biometrick lock of sensitive data/features.
It could be used in offline web apps (pwa) too.

As an example lets say Netflix that already utilizes crypto keys and you are always logged in, builds a pwa. It may download some films for offline usage and you can watch them in a train with bad wifi. It would be neat if netflix could require you to identify fast with your touch or face if you do sensitive things like removing devices, logging out or take a look at user data. For things that the server has to grant authorization, one can use a server generated challenge and verification combined with biometrics. For things like seeing offline data that might be sensitive a client side challenge would do the job (I mean the use case here is that someone that does not want to steal your device cannot see or do funny stuff easily, not hyper-hacker-cracker-security).

It would require from browser/OS a very little part of what webauthn already does and nothing more than what web crypto already does.

[prime2358]

Nice idea.

However, I am not sure user verification should be coupled with web crypto.
Why not just create a web biometrics API that is "above" the 3 linked OS APIs (and with time linux too)?

future web biometrics API:
verifyUser(osVerificationOption) would return some promise

existing web crypto api:
if user is the os account holder, use the existing sign(algorithm, privateKey, dynamicChallenge)

[twiss]

Hey 👋 I might be missing something but can't you do something like what you want today by combining the WebAuthn and Web Crypto APIs? E.g. something like

if (await navigator.credentials.get(...)) {
  await crypto.subtle.sign(...);
}

Also, from the perspective of the web app, wouldn't you want to verify the assertion from the token first, rather than trusting the OS/browser blindly? I'm not sure that the assertion is very valuable otherwise, as the client can always fake it. So indeed I also think it would be better to keep these APIs separate.

[r-jo]

Hi, thanks for responding.

Webauthn works with a pass manager and it is actually quite complex, I want to stay on browser level without any pass manager complexity and still have the extra access to biometrics / PIN to strengthen "browser key" signing which is possible today thanks to web crypto (I think Netflix pushed this and that is why we can stay signed in by Netflix in our browsers...) Now native apps and webauthn have access to os account verification of users, I would like to break this monopoly of webauthn for more alternatives and competition.

I understand you, but I think you still consider the old webauthn, creating device bound keys. However, with the passkey "reality" of Apple-Google-Microsoft that hijacked webauthn, the main characteristic is that keys are created, stored and synced on pass manager level, which might be too much complexity for some use cases. That is why here, with my suggestion, I am aiming for real device bound (rather browser in the os account) private keys AND(!) getting the second factor of os account ownership proof (biometrics, PIN). Some discussion about passkey evolution:
https://stackoverflow.com/questions/76660638/who-creates-the-passkey-and-how-many-will-be-created

By webauthn, using navigator.credentials.get() the pass manager residing in the os account has the private key, the pass manager signs over the server challenge as authenticator (if and only if the human proves the ownership of the os account with biometrics or PIN or other os account unlock method). The problem simply put: a pass manager is added complexity and not even everyone is willing to, or mentally equipped using a pass manager.

From the web app perspective, if I am not mistaken, this webauthn javascript call is the only (coupled) way to trigger os account verification and get information whether the real owner is using the device (more precisely os account).

@prime2358: I think we could and should have a way to do os account verification uncoupled from anything else from a web app if native apps can, but it would be a very long way to start a distinct web standard for this, I believe, while extending web crypto with the actual use case of getting this verification information from the os would be the much faster and easier way to go.

In addition, we could ride along with the current existing implementations(!) of webauthn in browsers and pass managers and even operating systems, making it easier "selling" this not that much work to browser implementors.

What I suggested would be:

• a little extension of web crypto signing with os account ownership proof (access to os biometric authentication results(!) the same way the signing process in webauthn does now)
• a simplification of webauthn where we do not need pass managers (built in or third party) and hence there is no syncing of private keys: the authenticator role and the pass manager role is played by the browser as client, under direct control of website owners and practically open source since chromium is open source

It is actually how webauthn started with "device" bound private keys, but there was no good answer to losing all devices and then "passkey" emerged from the ashes of former webauthn.
What I picture here with browser bound private keys is in a way more secure than passkeys (private keys synced around in pass managers) but without ultimate recoverability (which is actually by passkeys the utilization of the pass manager recoverability).
Adding recoverability against losing all devices is optional and may happen in a timely and technically freely chosen extra step: via paper pass manager, local digital pass manager, cloud pass manager. With password like strong recovery keys or weak recovery keys (where device + authenticated browser key is stronger) or even with passkeys.

The imagined authentication flow and use case would be:

• a user visits the website and gets an access token (stored as secure first party cookie)
• after some interaction and security & humanity checks against bots, we determine it is not a bot and we create in the server database an internal user id (uid) and register the device (browser) silently with ECDSA key pair, storing the public key on server, the private key in indexed db, unextractable to javascript (this private key is what I call browser key). With the browser key we can recover from clearing cookies or refresh expiring access tokens by signing a random server challenge with the browser key. This step would make much more sense if the signing and proof of possession of the private key would be coupled with a second factor of os account owner verification. An access token may be stolen somehow and hence a browser key is stronger proof of the device (netflix never asks to reauthenticate, they pushed the web crypto api and use browser keys) but for sensitive tasks authenticating the owner would be great.
• even without central pass (password, passkey, federated authentication) we can sync other devices on device to device basis (I use the word device actually for os account, more specifically a browser in an ideally private and protected os account). This way we can end up with 2-3 browser id->public key for an internal user id. Losing one device will not mean losing the account, which at this point is actually a silently created totally anonymous "account" as a service for a potential user without annoying account creation UX and headache in a first phase of a user-website relationship.

I call this device based account and security and I believe we are going in this direction (see Apple, Google signed in devices overview in the security part of their accounts, very cool).
There are two factors: possession of device (or real physical access to an os account on a device) and the biometrics / PIN as being / knowing something.
On your phone, you can change you Apple / Google password with biometrics / PIN, without providing the old password, now.
Passkey access is nothing else then this logic / model: trusted device + biometrics / PIN.
Trusted device is in this case the ones with installed signed in pass managers.

I have plenty of problems with passkeys though and I would prefer a browser key - recovery key model.
However, as of now, webauthn API and the passkey system has the privileged web access to the second factor (os account verification), which access I would like to have with browser keys too: competition is good.
The browser key would be a truly device bound private key and the human readable recovery key could be written down or stored in a pass manager (it may also be used to help syncing if the pass manager is synced).

The problem with passkeys:

• overcomplicated with verbose language and design flaws, halfway syncing and coupling with device bound physical security keys (even if in the end it is just simple syncing ECDSA private keys in pass managers).
• the burnt in requirement of pass manager when plenty of people do not want to use or cannot responsibly use pass managers. Hence website owners will always need another system for people opting out of pass managers. In addition there will be people who never really used a pass manager before and may not even know they are using one know, starting to create passkeys on 4 platforms: easy in the short run but security and maintenance hell in the long run.

So browser keys equipped with acces to biometrics / PIN + some recovery keys is better.

[fobinicca]

We definitely need alternative ways to access biometrics / PIN authentication success / failure (!) from the web.

Webauthn is extremely overcomplicated and the passkey "reality" of webauthn feels like an Apple kind of "solution".

It may work if we all lived in the Apple World and we all used Apple Pass Management (or Google World or Microsoft World).
Passkeys may be a step forward from federated authentication that was pushed for years and in the end poorly adopted, but just like that it is not really thought through: AGM has started already without pass manager equality and without any API for independent (and maybe open source...) pass managers. They do as if it was kind of magic, hiding the very important fact that you actually need a pass manager to store stuff. They try to lock people into Apple or Google pass management, they cannot really solve syncing since Apple, Google, Microsoft hate each other. Who cares for Linux users, who cares for adoption by users who resist pass managers, who cares for adoption by website owners who have to spend weeks with the badly designed webauthn specs to add another supposedly safer way of authentication (if you use a pass manager with autofilling passwords, you are protected against fishing too) and start the well said "maintenance hell" of many private and public keys on many different platforms and pass managers. Creating and using passkeys is one step, changing platforms, pass managers, deleting and changing stuff... well, we will figure it out! (or not)

I agree that some independent biometrics api would be cool but who will start and manage the web standard, especially if Apple, Google and Microsoft are now all-in on webauthn? It may take years that they realize or admit that the passkey system is another flop... Is it even possible to push a whole web standard without the blessing of Apple / Google? Especially with implicit access to device biometrics? 99% of operating systems are that of Apple, Google, Microsoft, Safari, Chrome and Edge are AGM.

So I vote for pushing for alternatives HERE, because the IDEA and LOGIC of device + biometrics / PIN authentication and using ECDSA or the like is really great and I believe it is the way to go. But not necessarily with the passkey & webauthn way of implementing this idea & logic. Competition is always good!

Since creating and keeping private keys in the browser and utilize ECDSA for browser authentication was made possible by web crypto (many thanks for that!), it seems to me the right place to extend this with biometrics / PIN here. I already have the logic built into my system. Now, I would just need to call the new sign() function if I need a 2 factor authentication for more sensitive things. Very neat and smooth.

Differentiating between stronger and weaker "device unlock" features is also crucial. I just upped my parents security (at least one of them did not resist the password manager) and demonstrated my father that it was 3 seconds for me to steal the "very complicated" figure he drew and if someone does this in a restaurant or elsewhere and then steal his phone, this someone can have access to: Google account, Google Password Manager, Gmail, SMS and can change: Google and all financial passwords without even knowing them, since all of them can be changed via email + sms. A strong device unlock is crucial nowadays. I would never use a weak one for sensitive things. A weak one is ok on client, offline, a strong one is definitely needed for server stuff.

Adding biometrics check (or rather strong device unlock checks) to the signing process is actually a very neat way to provide an extremely simple alternative to webauthn: we could be sure that not just the device (browser) that has the private key signed over the challenge but the owner of the device.

I already use private keys in the browser ("browser key") and I would be very happy if it was coupled with biometrics / PIN check!

[r-jo]

Thanks.
But if there is interest, I would be happy if we started to discuss the details...

Some synergy would be great, how exactly this "device unlock" access should be achieved here.

What I wrote was a first thought and I would be happy if in the coming weeks other people would "vet" it.

I have a lot of work right now, but I thought I write a quick reply: if we want to push this, it would be really great to get some deeper or more technical considerations / insights from others, not just "it would be great" in web crypto or it would be great independently in some other magic web standard :)

Of course I appreciate support, but realistically we have a very long way to go, and a crucial step is to get some concrete design on the table :)

[prime2358]

On second thought, it would still be best to create an independent biometrics check:
#352

We could use it for encryption / decryption or anything else.

[twiss]

Hey 👋 I just want to respond to one small part here:

I would like to break this monopoly of webauthn for more alternatives and competition.

and

So I vote for pushing for alternatives HERE

Different Web APIs aren't (and shouldn't be) in competition with each other. They are all shipped together within a single product, so it doesn't make sense for them to be. If you feel that WebAuthn is insufficient for some use case, you should contribute to the spec there. If you think it's too difficult to use, you could also propose or create a library to make it easier to use. But starting over with a new built-in API for very similar functionality, under the WebCrypto umbrella, is not the right way to go as it will make the web platform as a whole more complicated, not less.

[prime2358]

Web crypto is browser level crypto.
We cannot use webauthn for browser level authentication.

In case of authentication, to stay on browser level, we have to use web crypto with unextractable private keys in indexed db.
If I want to stay on the browser level for my use case, but I want to utilize biometrics, webauthn is not an alternative solution.

In this sense now I have to choose between: browser level without biometrics access or pass manager level with biometrics access.

A native app can opt out of a pass manager and use biometrics for its purposes, not a web app.

In addition, we could use biometrics to support other web crypto functions too, like I proposed here: #352

I do not want another web api to compete with webauthn: strong authentication via ECDSA like cryptography where keys are stored, managed, synced in third party pass managers.

I understand twiss but also r-jo.
I understand why r-jo wants a browser level ECDSA like authentication with biometrics access.
But I think what we actually want is biometrics support for all web crypto functions if and where it makes sense.

Stay on browser level, but utilize biometrics checks for signing or encryption / decryption.

If a native financial app checks biometrics and shows some local data or contacts the server and overwrites some data on server, why is it more secure than when a known browser is called to perform a biometrics check in a secure session? Trusted native apps (browser is a native app) performing os level biometric calls.

[r-jo]

competition is always good
chromium is great but I am happy if firefox and safari stay alive
linux or chromium variations are also healthy

but of course I understand what you mean with single product
however, webauthn is on platform/pass manager level
it will never be changed so that if someone calls it on an apple device than apple will ask you whether you want to store the key in the browser...
webauthn is a big conglomerate which was designed with security keys in mind and devices where you store the keys outside of browsers... then it was used by Apple/Google/Microsoft to build upon and make use of their faceid, fingerprint and windows hello

webauthn is not difficult, it is only needlessly complicated, I already implemented it (did you? try... an experience...)
it would be much nicer if apple or google creates the specs from the beginning, with a clear passkey mission in mind and not bend the specs afterwards...

• security keys would be separated with attestation
• the normal case would be like now: without attestation, private keys managed by third party pass managers / platforms?

nothing to contribute there, like you told me contribute to the pyramids or rather the jungle... it is done, it is what it is

I do not want to start over, I wanted a competing authentication solution where those who make the actual real work (implementations) have practically nothing to do

however, I wanted an extension of a web crypto use case (ECDSA like private key stored in indexed db to authenticate browser) with similar biometric access like webauthn (if there was made possible, why not here)

plenty of people implemented this since netflix pushed this API, we have an authentication logic that utilizes browser stored private keys... with a simple extra function we could write some if-else logic and an extra word and have an extra 2nd step of biometrics

the competing ideas would be using webcrypto extended with biometrics OR passkeys with the extra complexity of private key management on platform/pass manager whatever, tracking syncing or not syncing and 3-4 platform implementations, managing users who store passkeys on 4 platforms...

in addition, everybody has a recovery logic like passwords
passkeys cannot really replace passwords since some users will always resist pass managers and even if it was really platform bound, you would need a recovery from when all devices are lost

so you have a web crypto implementation and a password like implementation and you are supposed to add passkeys and maintain this complexity without getting rid of passwords and other complexity, why?

only because this is the only way to access biometrics from a web app and the idea of device posession + biometrics with ecdsa crypto is really cool

we could achieve this same cool factor just extanding web crypto signing with biometrics

I read #352
If it gets green light, I happily close this thread. It would even be better (if secure enough but I am not an expert) since we had decrypt with biometrics too which is also cool.

But I am really sure that either like proposed at 352 or coupling signing / decryption functions with biometrics (just like webauthn get() couples) would be a very nice and neat way of utilizing the modern biometrics capabilities that will be present in nearly 100% of devices in 5-10 years.

What do we want to do with biometrics?
It is not just authentication in the traditional sense like passkeys instead of passwords.
Normally if you have a device that is private and protected, you could stay logged in (like netflix).
However, a device has a time limit before it locks and it is security issue.

I do not want to force people with traditional passwords without pass manager to type their passwords each and every time so that their kid could not take a look or whatever. I can now only utilize biometrics from the web via webauthn call, passkeys and pass managers.

In this case we can reach webauthn level security with proposed function, utilizing biometric re-authentication from the browser coupled with web crypto proof of private key possession.

Actually that was not even my use case and here we could just use an unextracable decryption key.
Signing is rather for access token refresh or changing data on server.

So indeed, it is not webauthn, webauthn cannot be used for this (not even for signing since on deeper level than browser), it is a web crypto extension and although I understan the cooperative way of designing one thing right, the problem is we will know which one was more right only afterwards, moreover, each may have its use case.

Like there is passwords, federated, passkeys in the credential api, still nobody uses them for browser level stuff, we use web crypto for browser level stuff and web crypto does not have biometrics access :(

[twiss]

the competing ideas would be using webcrypto extended with biometrics OR passkeys with the extra complexity of private key management on platform/pass manager whatever, tracking syncing or not syncing and 3-4 platform implementations, managing users who store passkeys on 4 platforms...

Rather than trying to add WebAuthn-related things to WebCrypto, or adding WebCrypto-related things to WebAuthn, I would encourage you to think about what could be a way that the APIs can be used together in a way that achieves what you want. Or, if it's not possible today, what could be the minimal thing to add in order to make that possible.

Adding duplicate functionality from WebAuthn into Web Crypto just because you don't like the WebAuthn API is really not the right path. Those things should be discussed in the WebAuthn Working Group instead, as I wrote in #352 (comment).

[prime2358]

Can you elaborate on why is anybody trying to add "WebAuthn-related things" and where is "duplicate functionality"?

You state these things but they are simply not true in my opinion. It is only in your head which does not make it true.

The browser is not an authenticator, a pass manager is an authenticator or a security key.

What we want here is to use the browser without added complexity to store private keys. It is NOT possible via webauthn and it will never be. But it is possible with web crypto, a main use case! Please read use cases, number one!

Biometrics would be a second factor to existing web crypto(!) approach where we use the simplicity of a user agent to create, store and manage keys instead of "authenticators" that are pass managers. If you call webauthn create or get, you will get the complexity of a pass manager and security keys in real life. In your dreams it might be a place that offers the browser as an authenticator but you can forget it.

It is 100% web crypto API extension if we want a 2nd factor to existing web crypto API functionality.

If you do not want to work in the web standards group just push everything elsewhere then please quit.

And dont say false arguments.

"2. Use Cases
This section is non-normative.

2.1. Multi-factor Authentication
A web application may wish to extend or replace existing username/password based authentication schemes with authentication methods based on proving that the user has access to some secret keying material."