Tim Cappalli

@msft-bob looks like you're not in the repo so I can't assign review to you, but flagging for your feedback via comment

> This probably needs to take into account not only whether the client can support enterprise attestation, but also whether enterprise attestation is allowed for the calling RP. @emlun the...

> Ah, ok. In that case it's probably worth mentioning in the {{ClientCapability/enterpriseAttestation}} definition that the presence of this capability is no guarantee that the client's/authenticator's policy allows EA for...

Closing for the time being.

> The current paradigm creates a bad UX, because we have no way of knowing if a user has connected their current device to web auth, and so we either...

@AdamEisfeld passkeys are not intended to be used as secondary credentials / second factors. They are purpose built to replace traditional primary factors such as username/password and be the primary...

While it doesn't directly address your question/request, @MasterKale is working on improving some of the errors/exceptions in a way that maintains user privacy. https://github.com/w3c/webauthn/pull/2047

@Zhirui-Zhang please direct developer/deployment/implementation questions to [passkeys.dev/discuss](https://passkeys.dev/discuss) or the [FIDO-DEV list](https://groups.google.com/a/fidoalliance.org/g/fido-dev).

@rlin1 this is only used with UV=preferred. Spec text (line 7622): `[=registration extension|Registration=] and [=authentication extension|Authentication=] when {{AuthenticatorSelectionCriteria/userVerification}} is set to {{UserVerificationRequirement/preferred}}.` If an RP wants a fresh UV and...

> rather than the RP rejecting an assertion because all it could do was find out the time since last UV and then deciding it wasn't recent enough @sbweeden By...