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.

We discussed this proposal this week, and I was left with the task to figure out if I actively support the feature. To help with that, I had a question from me rather than the TAG as a whole:

• Is there an illustration of the benefit of immediate mediation over conditional? I see a flow without conditional mediation and a flow with immediate mediation, but nothing showing how the conditional autofill flow within the [username] box compares. Maybe there's a problem that the user needs to click that field, which could be alleviated if we give sites an imperative way to show that autofill prompt? Maybe it's that the user needs to click in the autofill box before seeing the system selector, which could be fixed if conditional let the page mark that it ought to show the system selector right away?

Given that credentials.get({'password': true}) also rejects instantly if the user hasn't stored any passwords (https://www.w3.org/TR/credential-management-1/#security-timing), I think we don't need much benefit of immediate over conditional, but there ought to be some just to justify the increased platform complexity.

Password credentials are not cross-site (or cross-origin?) in the same way that this is, but using that as justification for this runs afoul of our principles: just because passwords are bad, that doesn't excuse passkeys when they add the same badness. That is, password credentials should not reveal whether a password exists after site state clears.

I'm aware of the related website capabilities for webauthn, which might affect this. But I was more concerned about the cross-context problem. If someone clears cookies, having this leak that this happened (because it doesn't reject immediately) is a privacy leak.

I'm adding back the 'pending' status (which autoremoves whenever a non-TAG person comments) to wait for an illustration of the benefit of immediate over what's possible with conditional. I think @yi-gu might also have had some ideas that the team wanted to work through.