[webauthn] `publicKey` member name in `CredentialCreationRequestOptions` should be `"public-key"`, or vice-versa?

equalsJeffH has just created a new issue for https://github.com/w3c/webauthn:

== `publicKey` member name in `CredentialCreationRequestOptions` should be `"public-key"`, or vice-versa?  ==
forking the thread beginning here <https://github.com/w3c/webauthn/issues/750#issuecomment-403167486> into this new issue.

Here's the salient portions:

@bzbarsky wrote in https://github.com/w3c/webauthn/issues/750#issuecomment-403167486:
Does the spec actually describe what should happen when the .publicKey dictionary is missing?  As far as I can tell https://w3c.github.io/webauthn/#createCredential asserts it's present in the CredentialCreationOptions, but it's not clear to me what guarantees that, exactly...  It's also not clear to me when the "publicKey" member of CredentialRequestOptions ever gets used.

As long as the spec completely describes behavior when the dictionaries involved are missing, it should be fine as things stand.

@emlun wrote in https://github.com/w3c/webauthn/issues/750#issuecomment-403434610:
As far as I understand, the presence of the `publicKey` member is what triggers the client to invoke the WebAuthn methods instead of other Credential Management backends.

@emlun wrote in https://github.com/w3c/webauthn/issues/750#issuecomment-403584790:
I _think_ it happens [here](https://w3c.github.io/webappsec-credential-management/#algorithm-create), where _interfaces_ refers to [here](https://w3c.github.io/webappsec-credential-management/#credentialrequestoptions-relevant-credential-interface-objects) where _options_ is the options argument object sent to the `create()` method and the `[[type]]` slot for the [PublicKeyCredential][pkc] interface contains `"public-key"`.

...actually, does that mean that the [`publicKey`][publicKey] member name in `CredentialCreationRequestOptions` should also be `"public-key"`, or vice-versa?

[pkc]: https://w3c.github.io/webauthn/#publickeycredential
[publicKey]: https://w3c.github.io/webauthn/#dom-credentialcreationoptions-publickey

@equalsJeffH wrote in https://github.com/w3c/webauthn/issues/750#issuecomment-403631372:
Looking more closely at [credman](https://w3c.github.io/webappsec-credential-management/)'s magic [**relevant credential interface objects sub-algorithm**](https://w3c.github.io/webappsec-credential-management/#credentialrequestoptions-relevant-credential-interface-objects), i'm now thinking you & @emlun are correct, due to steps 4.2 & 4.3 in said sub-alg:
```
4. For each object in interface objects:
    1. [ . . . ]
    2. Let key be object’s [[type]] slot’s value.   // "public-key"
    3. If options[key] exists, append object to 
        relevant interface objects.                 // options[public-key] throws (?)
                                                    // i.e., it ought to be 
                                                    // options[publicKey] given  
                                                    // how spec is currently written.
```

So, perhaps browser implementors can weigh-in on whether it matters if we change..

1.  the [CredentialCreationOptions](https://www.w3.org/TR/webauthn/#credentialcreationoptions-extension) and [CredentialRequestOptions](https://www.w3.org/TR/webauthn/#credentialrequestoptions-extension) dictionary extensions' member name of `publicKey` to be `public-key`, or 
2. the [PublicKeyCredentialType](https://www.w3.org/TR/webauthn/#credentialType)'s enumeration value to be `"publicKey"`   (rather than the present `"public-key"`).

..i.e., what are present implementations doing, would making this spec fix affect them at all?

cc @kpaulh @agl @akshayku @jcjones 

[publicKey]: https://w3c.github.io/webauthn/#dom-credentialcreationoptions-publickey








Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1004 using your GitHub account

Received on Monday, 23 July 2018 23:54:27 UTC