- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Jan 2022 19:34:32 +0000
- To: public-webauthn@w3.org
> I am not particularly concerned about the big 3 platform authenticators they will support dpk and be certified or have a large enough base that RP will hard code their attestations and make decisions to trust them or not. > > The certification requirement is mostly for all the other authenticators that will implement multi-device strategies to compete in the consumer market. We are opening a can of worms here for more than just platform authenticators. Yes, although the can of worms has been open ever since the move from U2F to WebAuthn made attestations optional. That created two tiers of relying party implementations, and it sounds like there are assumptions that the 'no attestations' tier had assumed security properties. > I do think we need something separate from dpk as well to indicate if a credential is multi device and if it has been backed up/ durable or whatever we are going to call it. We should target behavior which relying parties need rather than implementation details here, similar to how we now talk about discoverable credentials rather than resident key credentials. We also should also clearly state for relying parties that any information given without attestations are advisory, e.g. they don't strongly state security properties. This may justify fewer, broader signals for non-attested use. Finally, it makes a lot more sense to have indicators for such things if the behavior is dynamic. An off-the cuff example would be a `isRecoverableCredentialCreationAvailable()` call in addition to new creation request options. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1020468949 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 January 2022 19:34:35 UTC