- From: Petr Dvořák via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Mar 2024 07:37:59 +0000
- To: public-webauthn@w3.org
Maybe one more "storytelling comment" on this...
When we started working on our FIDO2 HW token about two years ago, I read through the FIDO2 documents and thought: "This is great. We can send a challenge to an authenticator, and it will sign it."
Then we started implementing things and found out that `clientDataJSON`, which actually contains the challenge, is essentially useless as the bearer of the data, as it is sent to the authenticator ironed out via `SHA256` hash. While I understand the need for efficiency in interfaces like NFC/Bluetooth/USB (after all, some enterprises probably still run their COBOL apps on Windows 95), this is a neat candidate for abstraction in the standard so that we can decide to send `clientDataJSON` as a plain-text form to the authenticator, rather than hash and use the challenge itself for the WYSIWYS purpose.
From the specification, I understand the `clientDataJSON` structure is the following:
```
dictionary CollectedClientData {
required DOMString type;
required DOMString challenge;
required DOMString origin;
DOMString topOrigin;
boolean crossOrigin;
};
```
So, practically, it is something like this (non-minified, intentionally randomly found a bank with a long name, and used long challenge):
```json
{
"type": "webauthn.get",
"challenge": "cb48493c-a0c7-4a9d-9aed-a172724d4357&A1*A100CZK*ICZ2730300000001165254011*D20180425",
"origin": "moldindcondbank.md"
"topOrigin": "moldindcondbank.md",
"boolean": false
}
```
Is this so horrible in terms of size? I mean... the SHA256 hash almost makes the payload longer. ;-)
--
GitHub Notification of comment by petrdvorak
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2020#issuecomment-1985195294 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 8 March 2024 07:38:01 UTC