Use case:
As a user of a website with multiple Top Level Domains (TLD), I want to be able to store multiple passkeys for one Vault Entry.
Reason:
Passkeys are made so that they are usable only for one relying party ID to avoid phishing attacks => Each domain needs its own passkey
Real Life Example:
Amazon has TLDs for each market or country. As a user, you can order on multiple countries site (amazon.fr, amazon.com, amazon.de,…) to find the most interesting price.
Comparison with passwords:
With passwords, you can have one entry with an URL matching rule that catches all the TLDs at once.
For passkeys, you have to duplicate the vault entry for each TLD, which can lead to duplicate password (Amazon currently uses passkeys as 2FA) alert for Premium users.
If you had multiple URIs AND multiple passkeys in one entry, wouldn’t that be kind of messy? - Maybe then a passkey would have to be assigned to a specific URI within one entry so that this works? (BTW: how does it work now if I add a passkey to an entry where I have multiple URIs when a passkey is bound to a (which?) certain URI? )
Maybe this whole thing wouldn’t be a big problem, if there was the option to kind of disable entrys for the duplicate password report?
Maybe the URI to which the passkey is assigned should be visible to the user for more clarity. Right now, I don’t believe that an entry’s URIs are related to the domain the passkey uses. They can be totally different, I think.
This could be just a personal preference, but I don’t like the idea of having multiple entries for a single account with multiple passkeys. In some cases, even two entries for a single account wouldn’t be enough. That’s quite ugly, IMO. I like to have one entry per account.
Maybe then a passkey would have to be assigned to a specific URI within one entry
You’re right that a label could then be shown to tell the user which domain it is linked to. For me it should be done like that, because if we compare to how it was with passwords (to not change too much the user experience), you just had one vault entry per website, even if it had multiple domains.
That was due to 2 things: the password was the same on all those domains, and there were common matching rules (aka equivalent domains) on Bitwarden’s side to tell that amazon.com is the same as amazon.fr for example.
With passkeys, the private/public key pair is different for each domain from the same website, but I think it has to stay one website in the vault. It would be strange to duplicate the entry, as you would have “entry * number of TLDs” duplicates.
My opinion is that Amazon (I’m sure that other websites have the same issue) should create a Single Sign On (SSO) domain to rule them all for passkeys purpose, but in the meantime we have that issue.
Maybe this whole thing wouldn’t be a big problem, if there was the option to kind of disable entrys for the duplicate password report?
That would help to avoid the false alerts, or we could use the equivalent domains matching rules for it as well but that would not reduce the number of unnecessary duplicates in the vault.
@nothanco 1. Maybe the URI to which the passkey is assigned should be visible to the user for more clarity. Right now, I don’t believe that an entry’s URIs are related to the domain the passkey uses. They can be totally different, I think.
Yes, it’s the website that is sending a “relying party id” which is corresponding to the domain the passkey is linked to
My guess is that the URIs on the vault entry are used to find proposed entries with matching relying party, but for me it is not used for other things. I would like to get a confirmation on that
This could be just a personal preference, but I don’t like the idea of having multiple entries for a single account with multiple passkeys. In some cases, even two entries for a single account wouldn’t be enough. That’s quite ugly, IMO. I like to have one entry per account.
It’s partially true, because you can use the same credentials without having to recreate an account on each of their domains, they are recognized and Amazon is “creating” the account the first time you use your existing credentials on one of their domains.
But the items on the account are specific to that domain, like the orders, wishlists etc
StackExchange is a bit similar for that, you have your global account and you “create” a sub-account on each of the sites.
And they are all registered as equivalent domains on the global rules list.
But anyway, with passwords we had just one vault entry for it, because it’s still one site even if it has many domains, so I think we should be able to keep it like that with passkeys to avoid creating a mess in our vault.
This use case is also relevant for storing multiple passkeys of multiple Google accounts that can be logged in at the same domain accounts.google.com at the same time.
You would have to explain your use-case further, as Bitwarden’s functionality is designed based on the assumption that you have a separate vault item for each separate account. Trying to use a single login item to hold login credentials for multiple accounts is generally not recommended or possible (whether the credentials are in the form of a username/password or a passkey).
Why logging in with the second allow would ask me to create a second passkey. When this was offered to the Bitwarden client in the Firefox extension, it showed one big button for accounts.google.com and then wanted to overwrite the existing passkey for the first account, which I cancelled.
Differentiating passkeys additionally by account would allow to use different keys for each. The alternative is to approach Google and ask them to allow for reusing of the same passkey for multiple accounts, it may appear. Would such a use case be supported by the Bitwarden client?
What if you first manually create a second vault item (for the second account) with the same URI, before going to Google to create the passkey? Wouldn’t Bitwarden offer you both vault items, then?
take bitwarden for example, the login can be protected with a passkey, and the 2FA section is protected by another passkey(under webauthn) but the two keys don’t work interchangeably.
)
but that would not reduce the number of unnecessary duplicates in the vault.