W3C home > Mailing lists > Public > public-webauthn@w3.org > September 2017

[webauthn] should authenticatorExtensions really be a dictionary?

From: balfanz via GitHub <sysbot+gh@w3.org>
Date: Fri, 08 Sep 2017 18:00:33 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-256328837-1504893623-sysbot+gh@w3.org>
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

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