Let's have each platform/implementer write what they're doing/planning to do.

@akshayku Please fill in what Microsoft does

Chrome on MacOS keeps authenticator state per Chrome profile. In Incognito mode, the Touch ID authenticator currently is available and uses the authenticator state of the parent non-Incognito profile, but informs the user that creating a new credential would persist state beyond the lifetime of the Incognito session. In Guest Mode, Touch ID is not available.

Basic thought I had was, having different behavior in inprivate/incognito mode and regular mode gives away the knowledge of browser's operating mode to the RP. Which all browsers strive not to do that.

Above comment was for MacOS. How about Windows/Android?

I would prefer a warning to the user saying about the implications of creating a credential in incognito/inprivate mode and allowing the creation of the credential on each browser.

On the call of 2019-07-17, Akshay asked what Chrome does differently for Incognito on Windows. Based on a quick search it looks like we disable platform authenticators in that case. There we link to this Chromium bug which basically says “we should figure this out”.

Basic thought I had was, having different behavior in inprivate/incognito mode and regular mode gives away the knowledge of browser's operating mode to the RP. Which all browsers strive not to do that.

We certainly don't want to create an isIncognito() call. Thus easily observable behaviour changes that result in a low-noise analog of isIncognito() are bad.

I think registering / asserting a credential is abrupt enough that it doesn't count as “easily observable” (so long as there's no silent failures that are distinguishable), so it's isUVPAA that's the major worry. For Android and Windows, isUVPAA returns false in Incognito. This is a signal, but it's very noisy and thus hopefully useless for sites trying to figure out whether a Javascript context is in an incognito session.

As Martin notes above, we do support platform authenticators on macOS with warnings. I think the reason that we don't do something similar for Windows and Android is a lack of ability to conveniently show such warnings.

attempting to summarize the above such that we might address this issue by including said info in the spec in a Note (pls review the below):

Chromium behavior in incognito mode:

From the call of 2019-07-31:

We agree the putting some language in the spec about this, and aligning user agents' behaviour, makes sense. I think that language should be non-normative because I'm worried about introducing normative language around something that has hitherto been implementation defined.

We lean towards a system of notice about the persistence of credential creation rather than one of forbidding creating credentials in private modes, or one of making credentials ephemeral.

+1

I think this can be addressed in a milestone later than wd-03

On 2020-09-30 call:
@agl notes that having normative recommendation here is probably not approp. haven't recently heard complaints regarding this. behavior in incognito mode is typically browser-specific. closing it is fine.
@akshayku does not think this belongs in webauthn spec.