- From: Arnaud Dagnelies via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Feb 2022 11:29:45 +0000
- To: public-webauthn@w3.org
Sorry for being dumb, but I still don't get it. On the client side, you *have to* transform it in proper JSON to even send it to the server. And in order to get get the public key, you *have to* decode the CBOR stuff inside. So, from the perspective of a web developer, I don't understand why being directly decoded would be a problem. > Any non-binary, non-CBOR form would be generated by the server after validating the binary responses had proper integrity and were correct answers to the challenges created by the server. I haven't gone through the validation/verification part. Please take into consideration that an average developer has no idea about U2F and CBOR. What "we" are familiar with is to have a public key in order to verify a signature of some data. Almost always, these are just base64url encoded values sent around. So, in this spec, it feels highly unusual and strange that this unknown CBOR protocol plays such a crucial role ....actually, even after digging into the specs, I still don't know why the original CBOR encoded form would matter ...however with the spec being 165 pages long, it's of course extremely challenging to assimilate, so I probably missed the important part. If you want to make something really great, then make a `toJWT()` method, to obtain a signed Json Web Token 🎉 😁 ...that would be super easy to transmit over the wire, is familiar to every web developer and verification would be a breeze since it is a well known web standard with a mature ecosystem. In short, it would be great! -- GitHub Notification of comment by dagnelies Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1040163874 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 February 2022 11:29:47 UTC