Substitute enum types in dictionaries with DOMStrings

[jcjones]

This fixes issue #1376, auditing all enums passed into WebAuthn to ensure that WebAuthn can be extended without causing WebIDL failures for lagging implementations.

I believe I caught them all. I prefixed all the targets with >> in the list below:

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 PublicKeyCredentialRequestOptions {
    required BufferSource                challenge;
    unsigned long                        timeout;
    USVString                            rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
>>    UserVerificationRequirement          userVerification = "preferred";
    AuthenticationExtensionsClientInputs extensions;
};

dictionary AuthenticatorSelectionCriteria {
>>    AuthenticatorAttachment      authenticatorAttachment;
    boolean                      requireResidentKey = false;
>>    UserVerificationRequirement  userVerification = "preferred";
};

dictionary PublicKeyCredentialDescriptor {
>>    required PublicKeyCredentialType      type;
    required BufferSource                 id;
    sequence<DOMString>                   transports;
};

dictionary TokenBinding {
>>    required TokenBindingStatus status;
    DOMString id;
};

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

---

Preview | Diff

[jcjones]

This will need to rebase on #1393.

[equalsJeffH]

Overall LGTM, thx @jcjones! I've one comment below wrt consistency, and then an overall one regarding the Note: we added to 5.8.4. Authenticator Transport Enumeration (enum AuthenticatorTransport):

Note: The AuthenticatorTransport enumeration is not referenced by other parts of the Web IDL because that would preclude other values from being used without updating this specification and its implementations. It is important for backwards compatibility that client platforms and Relying Parties handle unknown values. Therefore it exists here for documentation and as a registry. Where transports are represented elsewhere, they are typed as DOMStrings, for example in transports.

...I'm thinking we ought to make that Note more general such that it applies to all the enums that are now effectively "registries", move the note somewhere, perhaps to a new subsection at the beginning of Section 5, and then have small Notes at all the enum registries that link back to the overall one.

WDYT?

[equalsJeffH]

where you are using the term "unset", do you mean by that "does not exist" (note link to infra spec)?

[jcjones]

where you are using the term "unset", do you mean by that "does not exist" (note link to infra spec)?

Yes, I'll update all that wordage - thank you for the suggestion!

[equalsJeffH]

Ok, thx @jcjones, LGTM, although, there's this one little outstanding comment #1392 (review). I suppose it's ok to land this without addressing the latter comment, tho then ISTM we ought to open an editorial issue containing that comment's substance. thx again.

[emlun]

Is this right? Shouldn't the RP just pass all values through (known or unknown) and let the client ignore the ones it doesn't need?

[jcjones]

But what does the RP do with an unknown value?

The authenticator says it supports USB and ZWave. Does the RP need to permit ZWave, or just ignore it?

[emlun]

Since this value isn't signed, the RP should never make permission decisions based on it, right (such decisions should be based on data derived from the attestation cert)? So I don't know what else the RP would do with this value other than echo it back to the client.

[jcjones]

@equalsJeffH : Please take a look at 42dbe07 , as the change is perhaps larger than we had initially discussed but I like the way this ties together better.

@emlun: Please see responses above. I'm OK with changing things, but maybe you can propose the changes you'd like to see?

Thanks and have a good weekend!

[equalsJeffH]

LGTM, thanks @jcjones !

we'll submit this suggestion as a issue