normal use case is 1 person per browser per domain and hence 1 single account per browser per domain

[r-jo]

I think the api is overcomplicated for simple and normal use cases like:

• a person has a device or uses a common device with an OS account of his/her/their own
• ergo everybody (should) have an own OS accout space with own browser space (like you log out from your google account and "chrome" pass manager that stores your credentials in your google account works flawlessly until you remove yoour chrome profile...)
• so a person has on a normal website ONE and only account because everything else is a design smell (like owning more than one gmail accounts just because we have to log in to sites with emails which is bad design and not privacy first or you can have 4x15gb free space instead of 60gb)
• I argue the normal way is to have one account per person per domain so the whole API should be prepared to offer a simple way to use it as such:

navigator.credentials.storeUnique(passcode) navigator.credentials.storeUnique(username, passcode) navigator.credentials.getUnique('silent')

if already stored, will not succeed... alternative methods may overwrite...

this whole aberration of names and id-s and pictures and multiple accounts to one domain is just not what should be... every browserspace should be private and everyone should just have one account as default... the browser is not the level for different people and different credentials... it is the OS

I think allowing multiple accounts per browser per domain should actually been discouraged and the API should mirror this

[r-jo]

I argue we should think about the normal and preferred use case and design api-s this way... The normal use case is private os accounts and private browser spaces which are protected on OS level (face id, touch id, account passcode, account pin). The normal use case should and will be to enter to this private protected browser space where we may have a pass manager. If we chose to have a pass manager we just want to be authenticated and the whole thing should and can be as silent as possible. In the future, without email, phone or usernames, just a long passcode which was generated by the server. Or if we used federated stuff like log in with google or apple, we do not want to remember how we entered the web app, so it is better to enforce only one way to authenticate (store and get)... Above should be default, all other complicated stuff discouraged and if people need it, possible...

[r-jo]

I as developer actually would need something like: navigator.credentials.storeUnique(passcode) then(which means success) -> continue catch(failed because already stored) -> navigator.credentials.replaceUnique(passcode) or do something else...

I did not have time to take a deep dive in user mediation but I guess the default should be silent so I actually need: navigator.credentials.getUnique() then -> success catch-> empty, deal with exception

I do not really see why the browser or the app should tell the user that passcode authentication is under way... I guess it is automatic or for own security to re-authenticate ot the user already told us he wants to authenticate to continue something or get authorization.

I am really happy this feature is available in Chromium based browsers but the whole api seems to be way overcomplicated.