I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
> use this to tether and lock you in to their platform.
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN."
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.
> But there is nothing stopping you from transferring these keys to a different device if you wish.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
> Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
> The google password manager and Apple devices will sync private keys as part of the password manager sync fabric.
This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
> There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
> I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that go away. And that's a key difference with passwords. It is work to make a password unportable.
----
At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
I would be more amenable to these kinds of conversations about the challenges of supporting arbitrary sync/export/import if I didn't have to start each of these conversations by calling out that arbitrary sync/export/import doesn't already exist. Because you're right, there hasn't been anyone who "has tried to define what that interchange format should be." That interchange format doesn't exist right now.
I don't think it's accurate or helpful if someone asks, "is this portable yet" to say "yes" when there is no interchange format and 3rd-party sync is an entirely theoretical future capability that companies are looking into, and there's outright resistance to building 3rd-party sync into the spec. Give reasons why that portability doesn't exist yet, sure. Promise about what will exist in the future, sure. But don't just say, "yeah, we're portable, you can sync keys" when both Safari and Android have huge limitations on when and where keys can be synced.
> So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up?
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
Yes, the process is automated within the same ecosystem, and we (finally) have a way to use a phone to e.g. authenticate to a computer and cross ecosystems. So far there is no process to batch migrate.
There _is_ a manual process to migrate. I get your desires and your concerns about users not understanding that they will have this multi-device process for migration today. I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
> I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
> > Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
I'm with you, Dan. It is grossly irresponsible for the industry to be pushing passkeys while fundamental problems like transferring from one ecosystem to another aren't solved yet.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
> actively push people away from using passkeys until this problem is solved.
I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website?
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of.
If the site insists on UV (User Verification) rather than UP (User Presence) a device which has no way to verify the user should reject that.
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.
True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.
And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party.
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.
Ever site I've accessed with a passkey lets you tie it to an existing account with a username/password, Google login, Apple login, iPhone, YubiKey, etc. I've not used a passkey where that was the _only_ auth I could create on an account.
The title of the article though is "the beginning of the end of the password." Google seems to be making it clear here that they eventually want to get rid of other login methods, they just don't think it's mature enough yet for them to do so.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
But they’re not the only one using passkeys. If you could have multiple passkey logins to an account, it’s not earthshattering if one of them becomes unavailable.
That's the intention yes, and it's a whole 'nother conversation about how many passkey-eligible devices people actually do have in reality, and how often they travel with all of those devices on their person at the same time and how often they're going to actually go through the extra steps of logging in on their secondary devices and adding a new passkey.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
> Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
What it does imply is that if you store your passkeys on Apple's keychain, migrating to Android becomes that much harder. (I assume that Google will provide an implementation of passkeys on iOS when that becomes available as an API, but it will be a cold day in hell before Apple provides access to its keychain on Android.)
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
Not now, but soon. Bitwarden's public statements over the past year, and their acquisition of passwordless.dev, would seem to indicate that they're working very hard on adding passkey support.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access.
I don’t see any way that passkeys kill account sharing.
What the other user says is that maybe those companies will only let 1 device per account to be registered. So you can’t have 2 devices to login. Harder to share.
In this case, Google, that isn't true and just they're mostly treated as special Security Keys ("yubikeys" etc).
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
It's not fear mongering to have and express concerns about a technology. Especially a technology that many people want to force everyone to use whether they want to or not.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
I think it's simpler than that. Expenditure is linked to trust. Companies and platforms that erode trust, make less money in the long run - they have to continually exert energy to attract customers. Companies / platforms that focus on building and retaining your trust have to work less hard to have you part with your money.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains.
I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.
I’m a cynic too, but I’ll also be optimistic about published statements. Goggle said they’re committed to supporting 3rd party passkeys when they announced android support. Apple, not so much though. I am hoping Google just does the right thing and makes this table stakes.
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right?
i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
> theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
> They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
The user giving authority to access their information.
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
But don't mix them up. The mind is more secure than the body because information cannot be forcefully extracted from the mind. Yet.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring or smartwatch, which should be more difficult to lose or have stolen than a phone.
Bitcoin has a nice solution for cryptographic keys with BIP-32/BIP-39. You use a single master key to deterministically generate all others via a HKDF. The single master key is produced from a 12/24-word phrase plus an optional passphrase.
A good opsec for bitcoin is to have several copies of a phrase (which can be etched into stainless steel), so there is no single point of failure if lost/stolen, and you can use several passphrases for different wallets, which you don't write down anywhere.
You can use a word phrase with no passphrase in a "decoy" wallet and monitor on-chain if any bitcoin are spent in it. This would alert you that your seed phrase has been compromised but would not compromise your passphrased wallets.
To replicate this kind of decoy with passwords, you could store a login for some service which emails you if anybody logs in.
The decoy method also provides plausible deniability. There is no way to prove that there exists any other keyrings with other passphrases, and there is also no way to prove that you have provided every possible passphrase, even if you have provided all of the ones you do use.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.