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: John Bradley via GitHub <sysbot+gh@w3.org>
Date: Wed, 27 Mar 2019 17:47:56 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-477276819-1553708875-sysbot+gh@w3.org>
I don't know that forbidden is worth breaking CTAP for.  I guess this could
be part of CTAP2.1

I think we need to discuss what Christian is looking for.
I think he wants to make a credential over CTAP that doesn't require a PIN
to create.
At the moment CTAP2.0 requires a pin or UV if it is set for the device.
So I suspect what he wants is going to need changes and a CTAP2.1
Our choices could be:
1) allow the creation of just non-resident credentials without pin
(probably needs forbidden to get the effect Christian wants)
2) allow the creation of both resident and non-resident without pin/UV
(wouldn't require forbidden)

I suspect that option 1 is less controversial than option 2, but we sort of
need to decide that before deciding if forbidden is required.

John B.

On Tue, Mar 26, 2019 at 4:09 PM Emil Lundberg <notifications@github.com>
wrote:

> I think the forbidden value requires a breaking change to the
> authenticator API.
>
> Currently the client simply forwards the
> options.authenticatorSelection.requireResidentKey (or false if not set)
> to the authenticatorMakeCredential
> <https://w3c.github.io/webauthn/#op-make-cred> operation. true means the
> authenticator MUST create a client-side-resident credential, and false
> means the authenticator MAY create a client-side- or a server-side-resident
> credential at its discretion.
>
> PR #1191 <https://github.com/w3c/webauthn/pull/1191> as currently written
> adds some logic where the client will contextually ignore authenticators
> based on their characteristics, but still ultimately sends the same
> requireResidentKey
> <https://pr-preview.s3.amazonaws.com/sbweeden/webauthn/pull/1191.html#effective-resident-key-requirement-for-credential-creation>
> parameter to authenticatorMakeCredential
> <https://w3c.github.io/webauthn/#op-make-cred>. This is probably the best
> we can do without breaking the authenticator API. However, when the
> authenticator is capable of both client-side- and server-side-resident
> credentials, then the existing Boolean requireResidentKey parameter to
> authenticatorMakeCredential <https://w3c.github.io/webauthn/#op-make-cred>
> doesn't capture the requirement that the authenticator MUST NOT create a
> client-side-resident credential.
>
> So I think we need to either
>
>    1. break the authenticator API, by introducing a new parameter that
>    replaces requireResidentKey, or
>    2. drop the forbidden value.
>
> (1) obviously has the downside of requiring change to CTAP as well, but it
> also comes with additional benefits for preferred and indifferent, as
> authenticators capable of both storage modalities can then decide based on
> context. For example, an authenticator with limited storage space could
> create a resident credential when preferred if there are 10 or more
> storage slots available.
>
> Thoughts on that?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webauthn/issues/991#issuecomment-476693460>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAD4J4F_lK05QcxswcO94euAiI_YI8NEks5vajg0gaJpZM4VLLRf>
> .
>


-- 
GitHub Notification of comment by ve7jtb
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/991#issuecomment-477276819 using your GitHub account
Received on Wednesday, 27 March 2019 17:48:01 UTC

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