Does this address your concerns?

Not really. At least, not for me personally. Though the API doesn't get to name a credential, this is new information leakage. I realize that attempting to read this bit carries the risk of showing prompts that will be very annoying, but I don't see sufficient justification for this.

If this is for first-time visits to a page or visits from people without any associated identification, as you note, it would be better to have an explicit user choice to log in - engaging the existing flow - rather than have this pop, conditional on there being a credential.

It seems that the set of cases where a user is unknown to a site, but has a usable credential for that site, is a fairly narrow set of cases.

• There is obviously the cross-site credentials in Related Origin Requests. Is that a primary use case? We haven't established a TAG position on this yet, but we have concerns about cross-site information flow, similar to those for Related Website Sets.
• A user who has cleared cookies is another potential candidate. But this design allows for invisible confirmation of a non-recognition, which is undesirable.
• What else did I miss?

Overall, the information leakage, both through the immediate failure and the API being disabled in private/incognito modes don't seem to be justified by these.

It sounds like the central question you are asking is whether the use case is genuinely compelling, since no level of information leakage is acceptable if it does not provide substantial user benefit.

However, the set of cases where this is relevant is considerably wider than what you list.

A significant factor that hasn't been noted is that passkeys sync across devices. So a credential created on one device should become automatically available on another device, browser implementation, and/or profile, as long as the user's passkey provider is available there.

For example, suppose a user creates an account on a website while browsing on their phone, and saves a passkey to the platform or a third-party password manager. Later, using a desktop computer, they navigate to the same site. The site does not have any information about who the user is, but when the user clicks a "Sign In" button on the page then this API enables the user agent to display the recently-created passkey.

We believe there is value in reducing the incidence of users encountering form-based sign-in pages on the web. They are often complex, offering multiple sign-in methods and putting the onus on the user to remember which one they need to use. This feature would provide a simple low-friction alternative for a user who has signalled their intent to sign in to the site.

The following situations are all cases where this feature would improve the user sign-in experience, because they require a site to have to offer all sign-in options:

• The user is browsing from a new profile, browser, or device.
• The user created an account on a different profile, browser, or device than they are currently using, and has not signed in on this one yet.
• The user has not visited the site within the window for the site's cookie expiry time, and cookies have been deleted. Many websites set short cookie expirations, for a variety of reasons, including regulations in some instances.
• The user has manually cleared cookies.
• The user wants to sign in with a different account than they previously signed in with.

You are right that sites can use cookies to offer simplified re-authentication flows when those cookies are available, but form-based sign-in pages are still commonly encountered on the web. We have received positive feedback from developers who believe this will improve the sign-in flow for their users.