- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jan 2022 22:41:39 +0000
- To: public-webauthn@w3.org
A birdshot of thoughts: While sites do not have _assurance_ that a credential is device-bound today without checking the attestation, I accept that there is a norm that it will be, and that syncing credentials does perturb that. However, on the operating systems where Google provides a platform authenticator (i.e. Android and Chrome OS) our plan is that non-discoverable credentials will continue to be bound to the device as they always have been. Thus any RPs currently/planning to use non-discoverable credentials(*) are not disrupted. (*) and those platforms don't support discoverable credentials yet(**). (**) sorry; we know. As noted above, sites that want to use passkeys and which feel that they can productively incorporate visibility about different devices into their risk calculations can use the device-bound key extension. This gives them the same device-bound properties as always, with additional information about who the sync provider believes the the user is. I hope that passkey support ships concurrently with support for that extension so that there's no gap. It is more work for the RPs to support, but it feels correct that sites with more complex needs deal with the more complex interface rather than the other way around. About the authenticator selection extension itself: We have never implemented it because we don't feel that authenticator discrimination is broadly a good thing. Multiple different RPs might each have locally valid reasons for wanting to select the authenticators that are permitted on their site, but the sum of this is that users need to have multiple authenticators to span the set of different site policies that they encounter, they have to remember which goes with each site, and they can't have the expectation that a given security key will broadly work where they want to use it. That argument isn't compelling in an enterprise setting where a company is distributing security keys for people to use specifically with their systems. Thus we wouldn't have a policy objection to supporting authenticator selection for RPs listed in an enterprise policy. But the feedback that we received was that depending on enterprise policy on the client was problematic. That's why enterprise attestation was incorporated in CTAP 2.1. It allows the policy to be contained on the security key itself and thus avoids this restriction. It's true that attestation is an after-the-fact rejection of a registration, but in an enterprise setting the enterprise is probably better equipped than the browser to communicate why a registration was rejected, and an enterprise always needs to check attestation if they want to require a specific authenticator because the client could ignore the authsel extension. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1688#issuecomment-1011516074 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 January 2022 22:41:41 UTC