W3C home > Mailing lists > Public > public-webauthn@w3.org > October 2018

Re: [webauthn] `CredentialRequestOptions` make otherwise valid values invalid in an undesirable way

From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
Date: Wed, 03 Oct 2018 20:00:22 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-426779698-1538596821-sysbot+gh@w3.org>
> So are you saying that we can leave WebAuthn's IDL written as it presently is, with various dictionary members declared with the required keyword?

Yes.

> And also we ought to add to the beginning of each of #createCredential and #getAssertion algs a step that checks for "required" options dictionary members' presence

Not quite, if I understand correctly how this works.  So to take a concrete example, let's look at `CredentialCreationOptions`.  The spec needs to define what happens when the `publicKey` member is not present.   If it _is_ present, then Web IDL will guarantee that its required members (e.g. `rp`) are also present.

I _think_  the idea is to not call the relevant  #createCredential at all if the corresponding member is not present in `CredentialCreationOptions`,  right?   As long as that's clearly defined, you should be all good.

This will give a behavior where passing `{}` or  `{ publicKey: undefined }` for the `CredentialCreationOptions` will not invoke the relevant #createCredential, while passing  `{ publicKey: null }` will throw.   I don't know whether that matches what Chrome does right now.

-- 
GitHub Notification of comment by bzbarsky
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/750#issuecomment-426779698 using your GitHub account
Received on Wednesday, 3 October 2018 20:00:24 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:35 UTC