New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-focus resident key descriptions on allowCredentials aspect #1197
Comments
Resident keys can be used with or without allowlist. Infact we use it in both the ways already. So reformulating this will break existing implementation/assumptions. I object to this change in reformulating the definition. |
This wouldn't break anything, it only makes the concept of resident keys useful to an RP, which it 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 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 (In fact, CTAP2 defines the 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. |
@agl remarked on the 2019-04-03 WG call that the terminology for resident keys (aka "resident credentials") conflates two disctinct aspects:
allowCredentials
, e.g.:...and that of the two, (2) is usually the more interesting one from an RP perspective. There was broad agreement on the call that we should reformulate the terminology to focus more on aspect (2) than (1).
See also: #991 (comment)
The text was updated successfully, but these errors were encountered: