W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2019

Re: [webauthn] Indicate resident key credential "preferred" during registration and find out what the authenticator offered (#991)

From: Shane Weeden via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Mar 2019 00:15:57 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-472230359-1552436156-sysbot+gh@w3.org>
To kick off the solutioning discussion - how do we expose this as part of the WebAuthnAPI? 

I don't know enough about CTAP2 to know if this is viable, but from a pure WebAuthn/RP perspective, here's a suggestion to start with that attempts to preserve backwards compatibility with the existing API. There are other options such as extensions, however I prefer not to go down the extensions route as I think it is important that all user-agents support this capability and therefore it be part of the core API.

Currently in L1, `options.authenticatorSelection.requireResidentKey` is of type `boolean`. This can't easily change without breaking backwards compatibility unless we could have `requireResidentyKey` be one of a couple of different data types (`boolean` OR the proposed `ResidentKeyRequirement`), so the proposal is to leave this parameter as-is. In L1, it is already OPTIONAL, and defaults to false. My suggestion is to ADD another optional member to the `AuthenticatorSelectionCriteria` dictionary, as follows:

**Part 1 - Allowing the RP to express that resident keys are "preferred", if supported, but that it's ok to fallback to non-resident**

dictionary AuthenticatorSelectionCriteria {
    AuthenticatorAttachment      authenticatorAttachment;
    boolean                      requireResidentKey = false;
    ResidentKeyRequirement       residentKey = "discouraged";
    UserVerificationRequirement  userVerification = "preferred";

enum ResidentKeyRequirement {

Only one of `requireResidentKey` or `residentKey` should be present in `AuthenticatorSelectionCriteria`, and use of `residentKey` is encouraged. If both are present and the user-agent supports it, `residentKey` takes precedence over `requireResidentKey`.

Logically, `residentKey` replaces `requireResidentKey`, with:
- `requireResidentKey=false` being equivalent to `residentKey="discouraged"` (this is also why "discouraged" is the default)
- `requireResidentKey=true` being equivalent to `residentKey="required"`

The new functionality is exposed via the `requiredResidentKey="preferred"` value.

**Part 2 - How authenticators report on what type of key was provisioned (resident / non-resident)**

Again there are several options including:
- Using one of the reserved bits in flags that's part of authData
- A new member of the attestation object (this is not signed, so don't like it)
- Extension data (I'd rather not use extensions for the same reason mentioned earlier)

My suggestion is to consider using one of the flags bits (e.g. bit 5). The flag could be used during both the registration ceremony (to indicate whether resident key was provisioned or not), and authentication ceremony (to indicate if a resident key was used). The latter is not really necessary because the server could remember if the CPK was resident following the registration ceremony.

**Other considerations**

The algorithm for creating a new credential (https://w3c.github.io/webauthn/#createCredential) will need to be updated to consider new processing rules for `residentKey="preferred"`.

Similarly, section 6.3.2 (https://w3c.github.io/webauthn/#op-make-cred) requires update in a couple of places, which probably also means CTAP2 requires update.

If the above suggestion were to be implemented, the IDL Index (https://w3c.github.io/webauthn/#idl-index) would also need updating.

GitHub Notification of comment by sbweeden
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/991#issuecomment-472230359 using your GitHub account
Received on Wednesday, 13 March 2019 00:16:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:02 UTC