[webauthn] should authenticatorExtensions really be a dictionary?

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

== should authenticatorExtensions really be a dictionary? ==
Currently, [authenticatorExtensions](https://github.com/w3c/webauthn/blob/14c2733ca6a4a9568e4c48fef1b870448818e811/index.bs#L1353) in the CollectedClientData structure is defined as a dictionary. The intention, presumably, being that different extensions are listed in there as different dictionary keys. For example, if we had two extensions, "foo", and "bar", and they both have authenticator extension inputs, the dictionary would look something like this:

```
{
  challenge: "LSKDJLKDJ...",
  origin: "example.com",
  authenticatorExtensions: {
    foo: "true",
    bar: { ... }
  },
  ...
}
```

I believe the purpose of the authenticatorExtensions field is for the client to convey, to the RP, what was communicated to the authenticator. One example extension that we specify - the location extension - not surprisingly says that the [authenticator extension input is the boolean "true"](https://github.com/w3c/webauthn/blob/14c2733ca6a4a9568e4c48fef1b870448818e811/index.bs#L3061), _**encoded in CBOR**_. 

What does that mean in terms of representing this in the authenticatorExtensions dictionary?

Proposal: the authenticatorExtensions field in the CollectedClientData should be a string (not a dictionary). Its content is the base64-encoding of the extensions parameter that the client sends to the authenticator during authenticatorMakeCredential and authenticatorGetAssertion.


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

Received on Friday, 8 September 2017 18:00:30 UTC