- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Apr 2019 22:47:13 +0000
- To: public-webauthn@w3.org
This wouldn't break anything, it only makes the concept of resident keys useful to an RP, which is currently, technically isn't. As the initial comment notes, there are two concepts here: _stateful_ credentials store their private key material on an authenticator, _initiating_ credentials can be used without providing an allow-list. An initiating credential must be stateful, but not vice-versa. Currently, the Webauthn spec [defines](https://w3c.github.io/webauthn/#resident-credential) resident credentials as stateful, and implies that means that they're also initiating. But U2F authenticators can be stateful if they wish—there's nothing stopping them from storing the private key and using a short index as a credential ID. Likewise CTAP2 authenticators can be stateful but, if `rk` was false when the credential was created, they may choose not to return such credentials for an empty allow-list and thus not make them initiating. (In fact, CTAP2 defines the `rk` flag thus: “instructs the authenticator to store the key material on the device”. So it's not precise that they actually need to be returned for an empty allow-list!) In order to be useful to an RP, a resident credential is one that it can get an assertion from with an empty allow-list. It's the _initiating_ property that they care about, not the security decision about whether the private key is wrapped and exported or not. But our specs are very confused about this. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1197#issuecomment-484714413 using your GitHub account
Received on Thursday, 18 April 2019 22:47:14 UTC