- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Jan 2022 14:17:07 +0000
- To: public-webauthn@w3.org
So to summarize some of the main points in this thread: **Without attestation, there are NO guarantees about how the authenticator works.** This has always been true, always will be, and passkeys will not change this fundamental fact. If an RP has some opinion that some authenticators, or authenticator features, are acceptable and some are not, the _only_ way to enforce that is through attestation. As stated in [ยง6.5. Attestation](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-attestation) (emphasis mine): >If an authenticator employs [self attestation](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#self-attestation) or [no attestation](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#none), then no provenance information is provided for the Relying Party to base a trust decision on. **In these cases, the authenticator provides no guarantees about its operation to the Relying Party**. Of course, if an RP does not actively enforce attestation requirements, then this is equivalent to the above scenario. So if an RP has implemented WebAuthn without collecting and validating attestation statements, and its security posture would be undermined by the introduction if multi-device passkeys, then that RP has unfortunately based its implementation on incorrect assumptions. That RP would have to start collecting and validating attestation statements, and revoke any existing credentials that don't satisfy the RP's requirements. There's nothing we can do from a spec standpoint to help or change that, but maybe we could somehow point all of this out more clearly to the reader. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1020147077 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 14:17:09 UTC