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: Emil Lundberg via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Mar 2019 14:21:04 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-472441706-1552486863-sysbot+gh@w3.org>
Thanks @sbweeden, I think this looks pretty good as a starting point, but (re @leshi) I think we need more discussion on the deeper implications of this before we're ready to move forward with a PR.

Part 1: WebIDL API
---

I mostly agree with your draft, but I would rename `"discouraged"` to `"indifferent"`:

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

enum ResidentKeyRequirement {
    "indifferent",
    "preferred".
    "required"
};
```

And the client/authenticator behaviour would be:

- If `"indifferent"`, the client MAY use any authenticator. The authenticator MAY create a non-RK credential or an RK credential, at its discretion.
- If `"preferred"`, the client should try not to use an RK-incapable authenticator. The authenticator SHOULD create an RK credential and MAY return an error if it cannot.
  - "MAY return an error if it cannot" is debatable - this could instead be "MUST create a non-RK credential if it cannot create an RK credential".
- If `"preferred"`, the client should try not to use an RK-incapable authenticator. The authenticator MUST create an RK credential and MUST return an error if it cannot.

We _could_ also add a `"forbidden"` value, but as noted in #1149 I don't think there's actually any use case for it.


Part 2: Authenticator report
---

This is where it gets tricky. Any change we make to what the authenticator returns will require changes to authenticators, and whatever solution we think up for L2, it will still be near impossible to know for sure whether a L1 authenticator created an RK or not. This means we probably need some way for the authenticator to signal that it's a L2 authenticator. For example, if we set a new flag bit to 1 to mean RK, then 0 could mean either "not RK" or "L1 authenticator (maybe RK)". Like the RK indicator, there are a few ways we could add an L2 signal:

- Use another reserved bit. That would mean we consume 2 of the remaining 4 flags and are left with only 2 for the future. Say we need another flag for L3, and a way to signal L3 authenticator, and we've already consumed all 4 reserved bits. Probably not ideal.
- New member of the attestation object. I agree this is undesirable since it's not signed, although the possible impact of tampering with this flag should be minimal.
- Extension data. We could then debate whether we should also lift the recommendation that RPs reject responses with extensions they didn't request, or if the RP should have to opt into receiving this extension output.

I agree that putting this in extension data is not ideal, but it might be the best option here since a single reserved bit isn't quite enough. What do others think?

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/991#issuecomment-472441706 using your GitHub account
Received on Wednesday, 13 March 2019 14:21:05 UTC

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