W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

Re: [webauthn] devciePubKey extension MUST be supported if passkey is supported (#1691)

From: David Waite via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Jan 2022 21:16:33 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1018865427-1642799791-sysbot+gh@w3.org>
To further elaborate on what Tim said:

WebAuthn (and AFAICT CTAP 2.1) do not define Authenticators as being implemented via hardware/devices, but rather as a more abstract concept. Credentials also aren't stated as being bound to hardware/devices - they are bound to an authenticator.

There have been conversations as well about the possibility of exportable credentials, which would require spec changes and be a new thing. However, an authenticator which is defined in terms of cloud hosting rather than encrypted flash storage is still an authenticator.

Passkeys, AFAIK, are an Apple product initiative name. A catchy name for sure, but we do not necessarily know what features this name means, or even if all of those features are within WebAuthn (or CTAP).

So there has been a bit of a struggle. Some have been struggling to find a descriptive name that describes what is coming, before we have consensus on which feature is meant to be inside the box. Others have been using a vendor term to describe what is inside the box, without a clear commitment to what will be shipped.

All that said:

Even if the specifications made hardware binding a MUST, a RP cannot tell from the assertions whether or not the credentials are within a trust zone of a non-upgradable, FIPS-compliant hardware key or are a lookup of a HTML table on the front page of some web domain. It cannot tell from an AAGUID whether it is dealing with a genuine product or someone who saw that key in debug logs and added it to their toy USB key project or Web Extension.

Policy decisions MUST stem from attestations, and the vendor guarantees or industry certifications which back them. There is simply no other technological measure to securely verify you are dealing with something meeting your policy, vs. say a Web Extension someone whipped up that sorta kinda behaves like a particular vendor's keys.

The problem statement is not that relying parties are going to start accepting authenticators that no longer meet their policy.

The problem statement is that a certain variety of authenticators need additional capabilities because otherwise, certain relying parties are not going to accept them. Relying parties then need to decide whether they want to leverage those capabilities in order to be able to accept those authenticators.

GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1018865427 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 January 2022 21:16:34 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:45 UTC