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

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

From: =JeffH via GitHub <sysbot+gh@w3.org>
Date: Tue, 26 Jun 2018 23:42:28 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-400496934-1530056547-sysbot+gh@w3.org>
Ok, @bzbarsky, I've been [RFTM](https://en.wiktionary.org/wiki/RTFM)'g here and have some questions...

Gecko implements this proposed resolution to https://github.com/heycam/webidl/issues/76:
> 1. A dictionary is "elidable" (better-naming-wanted) if it is either empty or only has members whose values are themselves elidable dictionaries.
> 2. When converting a dictionary to a JS value, skip over members whose values are elidable dictionaries, just like we skip over members that are not present.
> 
> For dictionaries that have default values that will still cause them to appear (with those default values)

..yes?

Assuming that what gecko implements (above?) is what is decided upon as the solution to heycam/webidl#76, **_AND_** if I understand the latter issue (and the related moz bugs) correctly, then I note that [`PublicKeyCredentialRequestOptions`](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions) et al has more `required` members than just `challenge`:
```
dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

    unsigned long                                timeout;
    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
    AuthenticatorSelectionCriteria               authenticatorSelection;
    AttestationConveyancePreference              attestation = "none";
    AuthenticationExtensionsClientInputs         extensions;
};

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
    USVString             icon;
};

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    required DOMString      displayName;
};

dictionary PublicKeyCredentialParameters {
    required PublicKeyCredentialType      type;
    required COSEAlgorithmIdentifier      alg;
};

```
..then it sounds like there are two more-or-less plausible approaches for the webauthn spec (again, [IIUC](https://en.wiktionary.org/wiki/IIUC)):

1. Remove the WebIDL "required" stipulation for all `required` `fooOptions` dictionary members (see above), and note in spec prose that if one does not pass all of them in with values when calling `navigator.credentials.{create(),get()}`, that the latter calls will not succeed (in some fashion: throw an error? return a null credential/assertion?). 

2.  Provide default values for all `required` `fooOptions` dictionary members, for example:
```
dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp  = {};
    required PublicKeyCredentialUserEntity       user = {}; 
    required BufferSource                        challenge = null;
   [...]
};

dictionary PublicKeyCredentialEntity {
    required DOMString    name  =  "";
    USVString             icon;
};

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id = null;
    required DOMString      displayName = "";
};
```
..(I'm not sure if the above syntactically correct). This would cause those dictionaries with default values to "appear" (with those default values), e.g. if someone does..
```
CredentialRequestOptions     bar = {};
```
..yes?

I'm not sure whether this covers all the bases. Nor, if it does, which is the "better" option.

thoughts?

-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/750#issuecomment-400496934 using your GitHub account
Received on Tuesday, 26 June 2018 23:42:33 UTC

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