43 ms·

The FIDO2 spec is written by someone who has no idea how web apis work. Lots of it is based on CBOR instead of JSON which makes it a PITA to handle in JS code (

The FIDO2 spec is written by someone who has no idea how web apis work. Lots of it is based on CBOR instead of JSON which makes it a PITA to handle in JS code (yes, there is a cbor npm library but why… WHY?!?).

robocat 4y ago
> CBOR Ugggghh. https://en.wikipedia.org/wiki/CBOR https://en.wikipedia.org/wiki/CBOR Negative numbers are encoded in such a way that can express a number than can’t fit into an int64. Undefined can be encoded. Floating point numbers are sent raw, so Infinity, -Infinity, -0, Signalling NaN, other NaN values can be encoded. A horrific choice for a security related API - a security API should never add unnecessary corner cases. Type 1 encodes negative integers, with a value of −1−count, for values from −2^64 to −1. The values 20–23 are used to encode the special values false, true, null, and undefined Short counts of 25, 26 or 27 indicate a following extended count field is to be interpreted as a (big-endian) 16-, 32- or 64-bit IEEE floating point value Edit: oh god no. https://www.rfc-editor.org/rfc/rfc8949.html https://www.rfc-editor.org/rfc/rfc8949.html Epoch-Based Date/Time allows 5 different integer or floating point representations (what to do with NaN numbers unspecified, so t+Infinity and beyond are representable). Tag number 36 is for MIME messages. Read the rest of the RFC for a truely hideous kitchen-sink specification.
pg_bot 4y ago
I agree that CBOR is unnecessarily shoe horned into the spec, but it honestly isn't that bad. IMO there are two other problems that need to be resolved for webauthn to go mainstream. The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. The second is the frontend JS API is a bit awkward to implement.
- tialaramex 4y ago
  > The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. You can't solve this "problem". The RPID is bound into the actual credentials, it isn't that there's no mechanism provided to change it, but rather that it is part of the credentials themselves. If you want actionable advice for people whose big boss has determined that they absolutely must change from foo.example to bar.example, they need to use the foo.example site to accept the credentials and forward users to bar.example and then re-enrol them to the "new" bar.example account with new credentials. Users will probably be annoyed about this hassle, but you can't do anything about that it was sealed in with the decision to get rid of foo.example. If your feedback is "But that's user hostile" yeah, so, don't change from foo.example to bar.example. What seems so very important to you is just another pointless annoyance for your users. Remember, you don't need to put the foo.example name on employee badges or the corporate logo to keep it, you only need to keep the name and use it to do the auth step. The same "Re-brand at all costs" thinking destroys users bookmarks, email address books, word-of-mouth, - destroys so much intangible value, and yet you can bet that the executives who decided upon it will argue that since they didn't measure that value they're destroying it doesn't exist.
tialaramex 4y ago
WebAuthn is a web protocol. FIDO however is a device protocol. On the Web, ASCII human readable JSON is a great choice. On a cheap USB device ASCII human readable JSON sounds like a lot of extra work for no reward. The device doesn't need to implement most of CBOR and if all you use it for is WebAuthn you don't either.

robocat 4y ago

> CBOR Ugggghh. https://en.wikipedia.org/wiki/CBOR https://en.wikipedia.org/wiki/CBOR Negative numbers are encoded in such a way that can express a number than can’t fit into an int64. Undefined can be encoded. Floating point numbers are sent raw, so Infinity, -Infinity, -0, Signalling NaN, other NaN values can be encoded. A horrific choice for a security related API - a security API should never add unnecessary corner cases. Type 1 encodes negative integers, with a value of −1−count, for values from −2^64 to −1. The values 20–23 are used to encode the special values false, true, null, and undefined Short counts of 25, 26 or 27 indicate a following extended count field is to be interpreted as a (big-endian) 16-, 32- or 64-bit IEEE floating point value Edit: oh god no. https://www.rfc-editor.org/rfc/rfc8949.html https://www.rfc-editor.org/rfc/rfc8949.html Epoch-Based Date/Time allows 5 different integer or floating point representations (what to do with NaN numbers unspecified, so t+Infinity and beyond are representable). Tag number 36 is for MIME messages. Read the rest of the RFC for a truely hideous kitchen-sink specification.

pg_bot 4y ago

I agree that CBOR is unnecessarily shoe horned into the spec, but it honestly isn't that bad. IMO there are two other problems that need to be resolved for webauthn to go mainstream. The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. The second is the frontend JS API is a bit awkward to implement.

tialaramex 4y ago
> The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. You can't solve this "problem". The RPID is bound into the actual credentials, it isn't that there's no mechanism provided to change it, but rather that it is part of the credentials themselves. If you want actionable advice for people whose big boss has determined that they absolutely must change from foo.example to bar.example, they need to use the foo.example site to accept the credentials and forward users to bar.example and then re-enrol them to the "new" bar.example account with new credentials. Users will probably be annoyed about this hassle, but you can't do anything about that it was sealed in with the decision to get rid of foo.example. If your feedback is "But that's user hostile" yeah, so, don't change from foo.example to bar.example. What seems so very important to you is just another pointless annoyance for your users. Remember, you don't need to put the foo.example name on employee badges or the corporate logo to keep it, you only need to keep the name and use it to do the auth step. The same "Re-brand at all costs" thinking destroys users bookmarks, email address books, word-of-mouth, - destroys so much intangible value, and yet you can bet that the executives who decided upon it will argue that since they didn't measure that value they're destroying it doesn't exist.

tialaramex 4y ago

WebAuthn is a web protocol. FIDO however is a device protocol. On the Web, ASCII human readable JSON is a great choice. On a cheap USB device ASCII human readable JSON sounds like a lot of extra work for no reward. The device doesn't need to implement most of CBOR and if all you use it for is WebAuthn you don't either.